elsa-core/src/modules/Elsa.Diagnostics.StructuredLogs
Sipke Schoorstra f969cd61e8
refactor(auth)!: retire the legacy permission constants and duplicate descriptor types (#7987)
* refactor(auth)!: retire the legacy permission constants and duplicate descriptors

Completes the cutover started in #7980. Seven `<Module>Permissions` classes
holding `verb:resource` strings are removed: AIPermissions, ConsoleLogs,
Dashboard, ExternalAuthentication, OpenTelemetry, Secrets and StructuredLogs.
AIPermissions was not in #7982's list, which was written before the cutover
finished; it is dead by the same measure as the rest.

Removed rather than marked obsolete, which #7982 asked to be an explicit
decision. Every string these classes held carries two colons, so it does not
parse under the new grammar and authorizes nothing. Keeping them obsolete
would leave code that compiles, still reads as a permission check, and
silently grants no access -- a warning that is easy to suppress in front of a
runtime failure that is invisible. A compile error names the call site and
can be fixed against the migration guide's mapping table. Classes their own
modules still reference, WorkflowPermissions and IdentityPermissions among
them, are untouched.

External Authentication's parallel descriptor system is collapsed onto the
core types: its own PermissionDescriptor record, its IPermissionDescriptorProvider
and IPermissionDescriptorRegistry, and DefaultPermissionDescriptorRegistry.

That was not only tidiness. The module's registry was fed exclusively by its
legacy names, so after the cutover every well-formed grant failed the
`unknown_permission_descriptor` check and the warning fired constantly for
correct configuration. The resolver now consults the core catalog, which is
keyed by resource and lists the verbs each accepts, and a wildcard is treated
as advertised because it names a pattern rather than a resource to look up.
The descriptor endpoint serves the core catalog too: choosing what an
external mapping may confer means choosing from everything Elsa declares.

The module contributes its resource descriptors explicitly rather than
relying on the host's assembly scan, for the same reason it registers
AddElsaAuthorization itself.

The two naming tests now pin the new resource name instead of the legacy
string. The convention worth holding was always that the module is called
'diagnostics/console-logs', not that a retired constant kept its old value.

Refs #7982

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

* fix(client): match the permission descriptor client model to the catalog

Moving the descriptor endpoint onto the core catalog changed its shape from a
single permission string to a resource plus the verbs that resource accepts,
and the Refit client model kept the old one. It still deserialized and still
compiled, handing callers a blank Name and no way to reach the verbs -- the
data went missing without anything failing.

The client model now mirrors the served descriptor, and a contract test
compares the two property sets so the next divergence is a test failure
rather than an empty field. NonCoreVerbs is excluded: the server derives it
from SupportedVerbs, so a client holding the verbs can compute it.

Found by review, not by the suites: nothing here throws.

Refs #7982

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

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 06:04:32 +02:00
..
Contracts [codex] Expose structured log storage diagnostics (#7446) 2026-05-13 16:32:23 +02:00
Endpoints/StructuredLogs fix(external-auth)!: wildcard-aware permission grant boundary, and startup smoke tests for both hosts (#7985) 2026-08-25 05:25:29 +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 refactor(auth)!: retire the legacy permission constants and duplicate descriptor types (#7987) 2026-08-25 06:04:32 +02:00
Providers/InMemory
RealTime
Services
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.