elsa-core/src/modules/Elsa.Diagnostics.StructuredLogs
Sipke Schoorstra 5862bb84e3
fix(build): make ConfigureAwait.Fody weaving actually take effect (#7983)
* fix(build): make ConfigureAwait.Fody weaving actually take effect

ConfigureAwait.Fody only rewrites awaits when it is handed an explicit
ContinueOnCapturedContext value. A bare <ConfigureAwait /> element parses
cleanly, emits no warning, and weaves nothing.

Of the 98 FodyWeavers.xml files under src/, only 22 set the attribute. The
other 76 carried a bare element, so those projects compiled with no weaving
at all while looking correctly configured. Verified on Debug net10.0 builds:
Elsa.Secrets (attribute set) referenced ConfiguredTaskAwaitable, while
Elsa.Alterations (bare element) did not.

Elsa ships as a library and can be hosted where a SynchronizationContext
exists, so weave everywhere rather than dropping the packages.

Fody reads the WeaverConfiguration MSBuild property in preference to any
FodyWeavers.xml, so the directive now lives in a single file, src/Fody.props,
alongside the package references it belongs with. All 98 per-project XML files
are deleted; they would otherwise be dead and misleading.

src/apps has its own props root that does not chain up to
src/Directory.Build.props, so it imports src/Fody.props directly instead of
redeclaring the Fody package references. This second gap was found by the
guard below, not by inspection.

Guard: Directory.Build.targets fails the build for any project that references
ConfigureAwait.Fody without an effective directive (ELSA0001) or that
reintroduces a FodyWeavers.xml alongside it (ELSA0002). Both were verified to
fire, including on the exact original bug shape.

The 22 already-weaving projects are unaffected: their effective directive is
identical before and after, and that set is disjoint from the four projects
holding explicit .ConfigureAwait( calls. All 25 such calls pass false, matching
what the weaver now applies, so they become redundant rather than contradictory
and are left in place.

Also repoints two security-assessment claims that cited the presence of
FodyWeavers.xml as evidence of weaving — the inference that masked this bug.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(build): drop FodyWeavers.xml from the new UserTasks modules

Merging main brought in eight new projects. Elsa.UserTasks carried a bare
<ConfigureAwait /> — the same latent no-op this branch removes elsewhere, added
while the fix was in review. Its seven persistence siblings set the attribute.

The guard caught it: ELSA0002 failed CI on the PR merge commit for all three
TFMs, on a file that never existed in the branch's own worktree.

All eight are redundant now that src/Fody.props supplies the directive.
Verified Elsa.UserTasks resolves it and its net10.0 build references
ConfiguredTaskAwaitable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 01:37:23 +02:00
..
Contracts [codex] Expose structured log storage diagnostics (#7446) 2026-05-13 16:32:23 +02:00
Endpoints/StructuredLogs feat(auth)!: structured authorization model, phases 1-6 (#7980) 2026-08-24 23:44:55 +02:00
Extensions [codex] Extract dashboard contributors into companion modules (#7692) 2026-06-05 14:30:52 +02:00
Features
Logging
Models [codex] Expose structured log storage diagnostics (#7446) 2026-05-13 16:32:23 +02:00
Options
Permissions feat(auth)!: structured authorization model, phases 1-6 (#7980) 2026-08-24 23:44:55 +02:00
Providers/InMemory [codex] Add structured log SQLite persistence (#7445) 2026-05-13 15:57:06 +02:00
RealTime
Services [codex] Add structured log SQLite persistence (#7445) 2026-05-13 15:57:06 +02:00
ShellFeatures Remove PackageManifestCategories and update feature categories to inline strings 2026-06-08 09:48:55 +02:00
Elsa.Diagnostics.StructuredLogs.csproj [codex] Extract dashboard contributors into companion modules (#7692) 2026-06-05 14:30:52 +02:00
README.md [codex] Expose structured log storage diagnostics (#7446) 2026-05-13 16:32:23 +02:00

Elsa.Diagnostics.StructuredLogs

Elsa.Diagnostics.StructuredLogs provides live structured log streaming for Elsa hosts. It captures ILogger events, redacts sensitive values, keeps a bounded recent-log buffer, exposes REST endpoints for recent logs and sources, and streams live events to Studio over SignalR.

This module captures semantic ILogger records only. Direct stdout/stderr console streaming belongs to a future diagnostics console logs module, and trace waterfalls, metrics, and span exploration belong to a future diagnostics OpenTelemetry module.

Enable The Feature

Register the module with Elsa:

services.AddElsa(elsa =>
{
    elsa.UseStructuredLogs(options =>
    {
        options.RecentLogCapacity = 5_000;
        options.MaxRecentLogQuerySize = 1_000;
        options.SourceHeartbeatTimeout = TimeSpan.FromSeconds(30);
    });
});

Then map the HTTP endpoints and SignalR hub:

app.UseStructuredLogs();

This maps the structured logs hub at /elsa/hubs/diagnostics/structured-logs and the REST endpoints under the configured Elsa API prefix.

Authorization

The recent-log endpoint, source-list endpoint, and storage-diagnostics endpoint require the read:diagnostics:structured-logs permission. The SignalR hub requires an authenticated user, matching the existing Elsa workflow hub authorization pattern. Grant read:diagnostics:structured-logs only to operators and developers who are allowed to inspect backend logs.

Studio Integration

Elsa Studio can use this module to show:

  • A recent log backfill when the page opens.
  • Live log events as the server emits them.
  • Level, category, message, tenant, workflow, trace, correlation, source, and time filters.
  • Cluster/source metadata such as source ID, pod name, namespace, container name, node name, machine name, process ID, and source health.
  • Storage pressure metadata such as dropped durable write counts and whether the active store reports storage diagnostics.

Clustered Deployments

The default in-memory provider captures logs for the current process only. It still includes source identity and Kubernetes/container metadata so Studio can filter and display the active source.

For persisted logs, add a storage package such as Elsa.Diagnostics.StructuredLogs.Persistence.Sqlite and opt in from the structured logs feature:

services.AddElsa(elsa =>
{
    elsa.UseStructuredLogs(structuredLogs =>
    {
        structuredLogs.UseSqliteStorage("Data Source=elsa-structured-logs.db");
    });
});

The core module remains storage-provider neutral. Custom stores can replace IStructuredLogStore while live updates continue through IStructuredLogLiveFeed; Studio continues to use the same REST and SignalR contracts, including source filtering, source-change notifications, and storage diagnostics.

Redaction

Log events pass through IStructuredLogRedactor before they are buffered or streamed. Configure StructuredLogsOptions to extend the default sensitive property names and text patterns.

Local Validation

  1. Start Elsa Server with UseStructuredLogs enabled.
  2. Open Elsa Studio with the paired Structured Logs module installed.
  3. Emit an ILogger message from the server.
  4. Verify the message appears in Studio's Structured Logs page.
  5. Change the level filter to Warning and verify lower-level logs are hidden.
  6. In containerized environments, verify the source list shows pod/container metadata.