5862bb84e3
* 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> |
||
|---|---|---|
| .. | ||
| Contracts | ||
| Endpoints/OpenTelemetry | ||
| Extensions | ||
| Features | ||
| Ingestion | ||
| Models | ||
| Options | ||
| Permissions | ||
| Providers/InMemory | ||
| RealTime | ||
| Services | ||
| ShellFeatures | ||
| AssemblyInfo.cs | ||
| Elsa.Diagnostics.OpenTelemetry.csproj | ||
| README.md | ||
Elsa Diagnostics OpenTelemetry
Provides the OpenTelemetry diagnostics collector surface for Elsa hosts.
This module owns the Core-side OTEL contracts, HTTP/protobuf ingestion, bounded in-memory diagnostics store, feature registration, permissions, read APIs, live update hub, and collector metadata that Studio consumes.
Scope
Elsa.Diagnostics.OpenTelemetry is collector/read-side diagnostics infrastructure. It does not create workflow spans, mutate Activity.Current, export telemetry to vendors, or provide durable OpenTelemetry persistence. Workflow telemetry production remains owned by existing Elsa.Workflows ActivitySource and Meter instrumentation.
The historical Elsa.OpenTelemetry module from elsa-extensions is intentionally not ported into this feature. It is producer-side workflow tracing middleware, duplicates current Elsa.Workflows instrumentation, and mutates Activity.Current; this module is collector/read-side diagnostics infrastructure.
Routes
OTLP HTTP/protobuf ingestion is exposed under OpenTelemetryDiagnosticsOptions.HttpEndpointPath, which defaults to /elsa/otlp/v1:
POST /elsa/otlp/v1/tracesPOST /elsa/otlp/v1/metricsPOST /elsa/otlp/v1/logs
Diagnostics read APIs are exposed through Elsa API endpoints:
POST /diagnostics/opentelemetry/resources/searchPOST /diagnostics/opentelemetry/traces/searchGET /diagnostics/opentelemetry/traces/{traceId}POST /diagnostics/opentelemetry/metrics/searchPOST /diagnostics/opentelemetry/logs/searchGET /diagnostics/opentelemetry/storageGET /diagnostics/opentelemetry/collector-configuration
Live updates are exposed through SignalR at OpenTelemetryDiagnosticsOptions.HubRoute, which defaults to /elsa/hubs/diagnostics/opentelemetry.
Security
All diagnostics read APIs require the OpenTelemetry diagnostics read permission. OTLP ingestion allows unauthenticated loopback traffic by default for local development only when no API key is configured. When OpenTelemetryDiagnosticsOptions.ApiKey is set, every sender must provide the configured API key header, including loopback senders.
Collector configuration returns endpoint and required-header names only. It never returns secret header values.
Storage
The default provider is bounded in-memory storage. Capacity options cover traces, spans, metric points, OTLP log records, and live subscriber queues. When a buffer exceeds capacity, the oldest item for that signal is dropped and diagnostics counters are incremented.