Skip to content

Add InvokeTracingMode.Full for full logging on InvokeAsync calls#2370

Merged
jeremydmiller merged 1 commit intomainfrom
invoke-tracing-full-mode
Mar 29, 2026
Merged

Add InvokeTracingMode.Full for full logging on InvokeAsync calls#2370
jeremydmiller merged 1 commit intomainfrom
invoke-tracing-full-mode

Conversation

@jeremydmiller
Copy link
Copy Markdown
Member

Summary

Addresses the community request from PR #2349 with a proper opt-in approach.

  • New enum: InvokeTracingMode with Lightweight (default) and Full values
  • New property: WolverineOptions.InvokeTracing controls behavior
  • New class: TracingExecutor — a separate IExecutor implementation that adds full structured logging to InvokeInlineAsync() (execution started, succeeded, failed, finished)
  • No runtime overhead: The executor type is selected at build time based on InvokeTracing setting — no if/then branching in the hot path

Usage

using var host = await Host.CreateDefaultBuilder()
    .UseWolverine(opts =>
    {
        opts.InvokeTracing = InvokeTracingMode.Full;
    }).StartAsync();

When enabled, InvokeAsync() emits the same log messages (event IDs 102-105) that transport-received messages already produce — execution started/finished, message succeeded/failed.

Files changed

File Change
WolverineOptions.cs Added InvokeTracingMode enum and InvokeTracing property
TracingExecutor.cs New IExecutor implementation with full logging
Executor.cs Updated Build() methods to select TracingExecutor when Full
invoke_tracing_mode.cs 5 new tests (default setting, lightweight no logs, full logs on success/failure/finish)
logging.md New "Full Tracing for InvokeAsync" section
tutorials/mediator.md Added tracing note
guide/http/mediator.md Added tracing note

Test plan

  • 5 new invoke tracing tests pass
  • CoreTests: 1214 passed, 0 failed
  • HTTP tests: 553 passed, 0 failed

🤖 Generated with Claude Code

By default, InvokeAsync() uses lightweight tracking without emitting
structured log messages. This adds an opt-in InvokeTracingMode.Full
that emits the same execution started/finished/succeeded/failed log
entries that transport-received messages already produce.

Implemented as a separate TracingExecutor class (rather than runtime
if/then logic in Executor) that is selected at build time based on
the WolverineOptions.InvokeTracing setting. This avoids any overhead
in the default lightweight path.

Closes the community request from PR #2349 with a proper opt-in
approach that doesn't impact default performance.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant