Fix the behavioural defects found in the OpenTelemetry tracing review

[lukebakken]

Note

Claude wrote the code, tests, and documentation in this PR, except for the commits merged from #1982, which @danielmarbach wrote. I directed the work, reviewed the findings, ratified the three judgment calls flagged below, and requested the code review that produced the follow-ups section.

Group A of #1967: the findings that are outright wrong behaviour rather than semantic-convention conformance.

The audit itself is in docs/internal/opentelemetry-tracing-review.md (first commit on this branch, already reviewed as part of #1967). Every claim marked verified there was settled by driving the real SDK pipeline against a live broker rather than by reading code.

Why group A ships on its own

None of these changes an attribute value or span name that a conforming consumer keys off, so they can land without anyone downstream having to re-key. Groups B (semantic-convention conformance, which breaks four existing test assertions) and C (per-provider tracing configuration, which must land before #1923) will stack on this branch as separate PRs.

One caveat on that: the publish span's duration does change substantially, as measured below. No attribute or name changes, but latency dashboards keyed on that span will move.

Ambient-span pollution

SessionBase.TransmitAsync and Connection.WriteAsync tagged whatever Activity.Current happened to be, because the frame-writing path has no reference to the publish activity it belongs to. TransmitAsync is on the path of every AMQP method, so any RPC issued inside a caller's span wrote ten messaging and network tags onto a span this library does not own - an application's own span, or an ASP.NET request span, picking up server.address and messaging.message.envelope.size from an incidental QueueDeclare.

Pre-existing in 7.2.1, not a regression from the connection-tracing work.

Fixed with an ownership check that tests the publisher source specifically, not "any activity from this library". That distinction is load-bearing: the connection spans are ours too, but they are not publish operations, so a library-wide gate would have left connection attempt still carrying messaging.message.envelope.size from the handshake frames.

The two ambient call sites now read Activity.Current inside the helper, behind the cheap HasListeners() test, since that is an AsyncLocal read on a per-frame path. SessionBase actually improves here - it previously read Activity.Current unconditionally to pass as an argument.

Failed operations never recorded an error

No publisher or subscriber span ever set a status, because the catch blocks sat outside the activity's using scope. A mandatory publish raising PublishReturnException, and a consumer callback throwing on every message, both traced as completely successful.

Fixed via one SetActivityError helper setting all three of the exception event, an Error status, and error.type. This is what the spec prescribes, not just a defensible choice: docs/general/recording-errors.md, which messaging-spans.md defers to ("Span status SHOULD follow the Recording Errors document"), says the status code MUST be left unset on success, and that on error instrumentation SHOULD set the status to Error, SHOULD set error.type, and SHOULD set the status description to the exception message. SetActivityError does exactly those three. error.type is Stable in the messaging convention, is Conditionally Required on failure, and was set nowhere before this PR. The helper also replaced five hand-rolled AddException + SetStatus pairs on the connection spans, so all three span types now report failures uniformly.

The publish case needed two catches, not one. PublishReturnException surfaces from MaybeEndPublisherConfirmationTrackingAsync, which runs in the finally because the confirmation is only awaited once the send has been issued. Moving the using out of the inner try and adding a catch there does not see it. That was the primary verified case, so the obvious fix would have looked complete and covered nothing.

Three judgment calls

Called out explicitly because they are choices, not defects:

1. The publish span now covers the full publish-and-confirm round trip. It starts above MaybeStartPublisherConfirmationTracking and MaybeEnforceFlowControlAsync, and - because the confirmation is awaited in the finally, which is now inside the activity's scope - it also ends after that await returns. That second half is the dominant effect. Measured over 300 warm iterations with publisher confirmations and tracking enabled:

	span p50	span p95	span/wall p50 ratio
main	37us	117us	0.047
this branch	372us	728us	0.960

The span went from ~5% of the wall-clock publish call to ~96% of it, about a 10x increase in reported duration. Nothing became slower: wall-clock publish time was the same order in both runs (p50 776us on main, 388us on this branch), and that gap is run-to-run noise between two separate probe processes, not a speedup. What changed is what the span means - "publish, including waiting for the broker to confirm" rather than "hand the frames to the socket". Publish-latency dashboards keyed on this span will jump by roughly an order of magnitude on upgrade to 7.3.0.

I think end-to-end is the more useful semantic, and it is what a consumer would expect a publish span to cover when confirmations are enabled. But it is a visible change, so it needs to be in the release notes and not buried as a flow-control aside.

2. A handled exception still marks the span Error. If MaybeHandleExceptionWithEnabledPublisherConfirmations swallows, SetActivityError has already run. The publish did fail, it was just reported through confirmations rather than by throwing.

There is spec text cutting against this, and it deserves to be argued rather than left unmentioned. recording-errors.md: "Errors that were retried or handled (allowing an operation to complete gracefully) SHOULD NOT be recorded on spans or metrics that describe this operation." The deprecation of exception.escaped rests on the same reasoning. The argument for keeping the Error status is the parenthetical: the operation did not complete gracefully. A nacked or returned publish is a failed publish, and the caller learns about it through the confirmation task instead of a throw. That is unlike the spec's own example, where ResourceAlreadyExistsException means createIfNotExists succeeded in its contract. So this is a judgment call against soft guidance rather than a conformance defect, and worth revisiting if it proves noisy. Flagging it explicitly because it is the one place in this PR where the spec's default and our behaviour differ.

3. Two exception events if both the try and the finally throw. Accurate, but noisier than one. This turned out to reproduce on a common path rather than an exotic one, and is fixed - see the follow-ups below.

For the 7.3.0 release notes

Three behaviour changes here are visible to anyone with dashboards or alerts on this client's spans. Collecting them in one place so they do not have to be reconstructed from the sections above at release time.

• Publish span duration jumps by roughly 10x when publisher confirmations are enabled, because the span now covers the confirmation round trip rather than just handing frames to the socket. Nothing got slower; the span measures more. Latency dashboards keyed on the publish span will move.
• Cancelled operations no longer produce Error spans. A publish or connection open that the caller cancels rethrows without setting a status, exception event, or error.type. Anything keyed on error.type counts will see a drop that reflects reporting, not reliability - this matters most for apps that cancel routinely on graceful shutdown or client-side timeouts. The spec supports this independently of the ASP.NET Core comparison that prompted it: exceptions-logs.md assigns DEBUG severity to "exceptions that don't indicate an actual issue", and its worked example is a request "cancelled on the client side".
• Failed operations now produce Error spans at all, which is the flip side: publisher and subscriber spans previously never set a status, so a nacked publish or a throwing consumer traced as a success. Error rates keyed on these spans go from zero to real.

Thanks @danielmarbach for pushing on the second one - the ASP.NET Core comparison in this comment is the clearest statement of why the distinction is worth making when the library has the token to make it.

Smaller items

• OpenTcpConnection was the only activity factory returning a bare activity and leaving its call site to tag it, which made it the one place a new caller could silently produce an untagged span. It now takes the endpoint and sets the server tags itself.
• OpenTelemetryContextExtractor relied on a blanket catch swallowing a NullReferenceException once per propagator field when Headers was null. It now returns early, as DefaultContextExtractor already did, and the catch is documented as defensive-only. This is the weakest finding in the set.
• DefaultContextSetter's comment claimed it preserved an existing header; it always overwrote. The overwrite is correct, so the comment was fixed.

Tests

Eight regression tests, each verified to fail without its fix - I removed the fixes and confirmed the failures rather than assuming. Seven are in TestActivitySource and one in TestOpenTelemetry. They live in SequentialIntegration because ActivityRecorder and the activity sources are process-global.

Worth knowing for anyone writing tracing tests: UseRoutingKeyAsOperationName defaults to true, so a publish span is named publish <routing-key>, and ActivityRecorder matches OperationName exactly. A recorder built for "publish" therefore records zero activities under the default configuration and fails with Expected: 1 / Actual: 0, with no hint that the name is the problem. Three of the tests hit this. The new PlainOperationNames scope guard pins the flag and restores the prior value on dispose - unlike the existing tests, which mutate that global and leave it, making outcomes order-dependent. That is group C's defect reproducing inside our own test suite, which is a fair argument for fixing it.

Verified against a live broker on Linux, with this branch rebased onto main at #1971:

Suite	Result
Tracing (TestActivitySource + TestOpenTelemetry)	60 passed
SequentialIntegration (full)	72 passed, 3 skipped
Integration	200 passed, 6 skipped
Unit	147 passed

net8.0, netstandard2.0, and the OpenTelemetry package all build with zero warnings.

I flagged one unverified risk when this went up as a draft: netstandard2.0 is built but not run locally, and Activity.AddException comes from the DiagnosticSource package on that target, while this PR increases its call sites to include the per-delivery path. CI has since come back green on all 10 checks, including build-win32 and sequential-integration-win32 (which is where the new tracing tests run), so that risk is closed.

Review follow-ups

All four addressed; out of draft. A review pass over the branch turned these up, three of them verified with a probe against a live broker:

• Duplicate exception events on the closed-connection publish path. Both the inner catch and the finally's catch called SetActivityError, because MaybeHandleException stores the exception on the confirmation TCS and the finally's await then re-raises it. Publishing on a closed connection yielded events=2 with AlreadyClosedException recorded twice; an unroutable mandatory publish correctly yielded events=1. Judgment call 3 above, but on a common path rather than an exotic one. Fixed with an exception filter comparing by reference against the exception the inner catch recorded, so the duplicate is suppressed while a genuinely different exception from the confirmation await is still recorded. The tests missed it because ActivityAssert.HasRecordedException only inspected Events.First(); it now asserts Assert.Single over the "exception" events, so all the failure tests assert the count.
• SetActivityError applied its three signals inconsistently under sampling. AddException and SetStatus were unconditional while error.type sat behind IsAllDataRequested. With a listener sampling PropagationData, the span got the exception event and the Error status but no error.type - a PropagationData span is still delivered to ActivityStopped with its tags and exception events intact, so the gate recorded the expensive signals and dropped the cheap one. Fixed by making all three unconditional, gated only on a null activity.
• No test for the OpenTelemetryContextExtractor null-Headers guard. Fixed: TestContextExtractorHandlesPropertiesWithNoHeaders_GH1967.
• All five new recorders set VerifyParent = false, so span parenting was unasserted. Fine for the failure-recording tests, but the ambient-activity test is exactly where a parenting regression would show up. Fixed: that test now asserts the publish span is a child of the caller's activity, so scoping the tags to the publisher source cannot silently detach the span from the caller's trace.

Review notes

Two of the three judgment calls stand as choices: the span now covering the confirmation round trip, and Error status on a confirmation-handled failure. @lukebakken has ratified both, and they are the parts most worth a second opinion - particularly the first, given the size of the duration change. @danielmarbach has since reviewed the second and agrees with the direction. The third (duplicate exception events) is fixed.

@danielmarbach independently reviewed the same fixes and opened #1982; those commits are merged into this branch, so the caller-cancellation fix, the filter-based dedup, the unconditional SetActivityError, and the strengthened HasRecordedException are all his. My gating of error.type behind IsAllDataRequested was wrong and is reverted - a PropagationData span is still delivered to ActivityStopped with tags intact, so gating it dropped the one signal that error-rate queries actually key off.

Tagging the people with the most history on this client's tracing implementation, since group A sets the error-recording and ownership conventions that #1980 (semantic-convention conformance) and #1970 (recovery spans) will both build on - easier to change now than after 7.3.0 ships:

@stebet (the original implementation and the OpenTelemetry registration/propagation work), @tmasternak (recommended by @danielmarbach on #1970), @iinuwa (brought the attributes in line with the current messaging conventions), @lmolkova (the spec/conventions questions), @eerhardt (opened #1731, the parent of the connection-span work), @aygalinc (implemented the connection spans this extends).

No obligation to engage. The conventions established here are summarised in #1979.

Span events are on a deprecation path (#1992)

@tmasternak raised that OpenTelemetry is deprecating the span-event API in favour of the Logs API. Verified against the raw specification markdown: exceptions-spans.md is marked Status: Deprecated, exception.escaped is deprecated outright, and both exception documents carry a normative block telling existing instrumentations to introduce OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN with logs and logs/dup, keeping span events the default while unset.

This does not change what ships here. Of the three signals SetActivityError sets, only AddException is affected; the Error status and error.type are prescribed by recording-errors.md and are unaffected. And nothing in the .NET stack supports the migration yet: on DiagnosticSource 9.0.4 none of AddException, AddEvent or SetStatus carries [Obsolete], the env var appears in no OpenTelemetry .NET assembly including OpenTelemetry.Api 1.17.0, and OpenTelemetry.Instrumentation.AspNetCore 1.17.0 still records via Activity.AddException. RabbitMQ.Client 7.x is a stable major version, so 7.3.0 keeps span events. Having all three signals behind one helper is what makes the eventual swap a single edit.

One related defect found while checking this, deliberately not fixed here: in AsyncConsumerDispatcher the deliver activity's scope closes at line 55 while OnCallbackExceptionAsync fires at line 77, outside it, so Activity.Current has already reverted (verified with a probe). Harmless today, but exceptions-logs.md requires exception events to be associated with the corresponding span context, so it becomes a MUST violation once exceptions are logs. It is a scope change with no present-day symptom, so it belongs with the migration and its own test rather than in a bug-fix PR. Tracked with the rest in #1992.

Scope

Part of #1979. Closes nothing on its own - #1967 stays open as the review of record, with the remaining work split into #1980 (group B, semantic-convention conformance), #1981 (group C, process-global configuration, which gates #1923), and #1992 (span events to Logs API).

[danielmarbach]

A few minor suggestions with additional context in the commit messages #1982

[danielmarbach]

I wanted to follow up on judgment call 17f82c5 from the review notes, the one about marking the span as Error even when the exception is handled by publisher confirmations.

I compared this against how ASP.NET Core handles the same question in its hosting layer. Their SetActivityEndTags method treats every exception the same. If the exception is not null, it sets error.type to the exception's full type name and calls SetStatus(ActivityStatusCode.Error). No distinction between a timeout, a null reference, or a caller cancellation. All of them produce an Error span.

That approach is simpler, but it comes with a cost. Every cancelled request, every client disconnect, every graceful shutdown creates an Error span. That noise makes it harder to spot the signals you actually care about.

The RabbitMQ code separates caller-initiated cancellation from everything else. When the caller cancels, the span stays clean. When the operation genuinely fails, the span gets the Error status. That distinction is possible here because the code has access to the CancellationToken and can check IsCancellationRequested. ASP.NET Core's hosting layer
does not have that context, which is probably why it defaults to the simpler approach.

I think the RabbitMQ direction is the right one. The library has the context to make the call, and it uses it. The only thing I would suggest is making sure this is called out in the release notes, so consumers know that cancelled operations will no longer produce Error spans after upgrading. That is a visible change if someone has dashboards or alerts keyed on error-type counts.

[lukebakken]

Thanks, that framing is more useful than the one I had. I was treating "do not mark caller cancellation as an error" as self-evidently correct; the ASP.NET Core comparison makes clear it is a choice that depends on having the token, and that the simpler unconditional approach is a defensible default when you do not.

Worth separating the two judgment calls, since the commit you linked (17f82c5) is the cancellation one but your opening line describes the other:

• Judgment call 1, caller cancellation - your comment. Cancelled operations no longer produce Error spans. This is your code, merged from Otel suggestions #1982.
• Judgment call 2, handled exceptions - a publish whose failure is reported through publisher confirmations rather than by throwing still marks the span Error, because SetActivityError has already run by the time MaybeHandleExceptionWithEnabledPublisherConfirmations swallows. Unchanged, and I still think it is right: the publish did fail, only the reporting channel differs.

Both stand as-is.

Added a For the 7.3.0 release notes section to the PR description covering the three visible behaviour changes: the ~10x publish span duration increase, cancelled operations no longer producing Error spans, and failed operations now producing them at all. Your point about dashboards keyed on error.type counts cuts both ways, which is why the third is in there too - error rates on publisher and subscriber spans go from structurally zero to real, and someone alerting on a jump in error.type will see one for reasons that predate this release.

CHANGELOG.md is generated from issue and PR titles, so the PR description is what the release notes get written from. Cited your comment there.

[gfoidl]

Why a separate local instead of having the condition in the if directly?

Same below.

[tmasternak]

I would like to provide a piece of context regarding exposing exception details via OpenTelemetry. This is somewhat orthogonal to the design decisions mentioned; however, it could influence the concrete implementation approach.

OpenTelemetry is in the process of deprecating the Span Event API in favour of the Logs API. In other words, it is assumed that sooner or later all Events API calls will be migrated to the Logs API calls. The change assumes this process will take some time and provides explicit guidance for instrumentation authors.

Span.AddException event

In the context of exceptions (as of 3.08.2026), semantic conventions for exceptions (spans) that describe capturing exception details as events on a span have already been deprecated. The spec defines both a new, preferred approach and a migration strategy for existing instrumentations (repeating the general migration guidance for instrumentation authors).

In short, the recommendation says (this is my simplification): instead of an event on a span, exception details (type, message, and details) should be captured as a LogEntry. What is left on the span is the Error status to indicate that the exception was thrown. If a backend for OTel logs supports finding entries by SpanID, this is enough for the operator to find exception details in logs based on the status and ID of a span.

RabbitMQ Client

In terms of implementation, this has at least two potential implementation consequences:

• the instrumentation API for the library should at some point respect the OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN configuration option
• logging of the exception should happen in proper OTel context to enable capturing TraceID\SpanID on a LogEntry. In practice, this means that any logging and/or user-callback invocations initiated by the rabbitmq-dotnet-client exposing exception details need to happen in the context of a span on which previously an event would be stored.

[lukebakken]

Thanks @tmasternak for your input. Personally, I know next-to-nothing about OTel. Do you have a client library or libraries that the 🧞 (AI) and I can use as a good, modern reference? It's either that or I depend on the goodwill and free time of people like you to get this work shipped, or I yolo-it and hope for the best 😸 Thanks!

[danielmarbach]

@lukebakken @tmasternak and I collaborated on the Otel skill I sent you together with Mauro who was the original author. We tried to incorporate as much as possible the spec as well as our practices. We will continue to refine it as we go. It should get you and the genie pretty far.

The log integration change probably requires deferral because, as far as I understand, it would require hooking up ILogFactory somehow to the client, and that most likely requires a bit more thinking given it is a new dependency too.

[lukebakken]

@danielmarbach thanks for reminding me of that. I didn't put 2 + 2 together, obviously 😅

[lukebakken]

Note

Written by Claude (Anthropic's Claude Code), directed and approved by @lukebakken. The specification findings are @tmasternak's; the verification, and the error it turned up, are Claude's.

Thanks @tmasternak. I went through the raw specification markdown rather than the rendered pages, and your points hold. Checking them also turned up an error of mine in this PR, which is now fixed.

Your claims, confirmed

docs/exceptions/exceptions-spans.md is Status: Deprecated, pointing at exceptions-logs.md. exception.escaped is deprecated outright. Both exception documents carry the same normative block, verbatim:

Existing instrumentations that record exceptions as span events:

• SHOULD introduce an environment variable OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN supporting the following values:
  • logs - emit exceptions as logs only.
  • logs/dup - emit both span events and logs, allowing for a phased rollout.
  • The default behavior (in the absence of one of these values) is to continue emitting exceptions as span events (existing behavior).
• SHOULD maintain (security patching at a minimum) their existing major version for at least six months after it starts emitting both sets of conventions.
• MAY drop the environment variable in their next major version and emit exceptions as logs only.

Also worth noting for the record: the six-month dual-emission maintenance commitment is a release-planning constraint, not just an implementation detail.

Where I was wrong

Two things, both mine.

"error.type is the only Stable attribute in the messaging convention" was false. I wrote that in the code comment, the internal review doc, and this PR's description. The producer-span table in messaging-spans.md also marks server.address and server.port Stable, and the consumer tables add network.peer.address and network.peer.port. What is true is narrower: every messaging.* attribute is Development, and the Stable ones in those tables are borrowed from other registries. The conclusion it was supporting is unaffected, since error.type is Stable, is Conditionally Required on failure, and was set nowhere before this PR. All four places are corrected.

I had also been reading the wrong document. I thought the spec said nothing about span status. It does, in docs/general/recording-errors.md, which messaging-spans.md explicitly defers to ("Span status SHOULD follow the Recording Errors document"):

[Span Status Code] MUST be left unset if the instrumented operation has ended without any errors.

When the operation ends with an error, instrumentation:

• SHOULD set the span status code to Error
• SHOULD set the error.type attribute
• SHOULD set the span status description [...] When the operation fails with an exception, the span status description SHOULD be set to the exception message.

SetActivityError sets exactly those three, including the exception message as the description. So the core of this PR is directly conformant rather than merely reasonable, which is a better footing than I had it on. Your point sharpens the scope too: of the three signals, only AddException is on a deprecation path. The status and error.type are unaffected.

One place the spec cuts against us

Since I am citing recording-errors.md in our favour, the same document has a line against judgment call 2:

Errors that were retried or handled (allowing an operation to complete gracefully) SHOULD NOT be recorded on spans or metrics that describe this operation.

Our behaviour is that a publish whose failure is reported through publisher confirmations still marks the span Error. The argument for keeping it is the parenthetical: the operation did not complete gracefully. A nacked or returned publish is a failed publish; the caller learns about it through the confirmation task rather than a throw from BasicPublishAsync. That differs from the spec's own example, where ResourceAlreadyExistsException means createIfNotExists succeeded in its contract. So we are reading it as a judgment call against soft guidance rather than a conformance defect, but I would rather flag it than have you find it.

Conversely, judgment call 1 gets independent support from your document. exceptions-logs.md assigns DEBUG severity to "exceptions that don't indicate an actual issue", and its worked example is a request "cancelled on the client side". @danielmarbach reached that conclusion from an ASP.NET Core comparison; the spec agrees, which is a stronger basis than either of us had.

Why 7.3.0 still ships span events

The guidance for stable major versions is to stay behaviorally compatible for now, with migration planned for the next major. Note the rc version of RabbitMQ.Client.OpenTelemetry does not give us extra latitude: that package is one ~90-line file of registration and propagation, emits no spans, and calls AddException nowhere. The whole tracing surface, including RabbitMQActivitySource, RabbitMQTracingOptions and the source-name constants, is in the shipped public API of the GA RabbitMQ.Client. A consumer can collect these spans with plain OpenTelemetry.Api or a bare ActivityListener without touching the rc package.

The .NET ecosystem has also not moved, verified rather than assumed:

• On System.Diagnostics.DiagnosticSource 9.0.4, none of Activity.AddException, Activity.AddEvent or Activity.SetStatus carries [Obsolete] or an experimental attribute. RecordException does not exist in .NET.
• OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN appears in no OpenTelemetry .NET assembly, including OpenTelemetry.Api 1.17.0, the current release.
• OpenTelemetry.Instrumentation.AspNetCore 1.17.0, also current, still records via Activity.AddException behind its RecordException option.

Your second consequence is a real defect

The logging-in-span-context point is the one with a concrete consequence here, and it is worse than hypothetical. exceptions-logs.md states:

Exception events emitted by instrumentations that also record spans for the same operation MUST be associated with the corresponding span context.

In AsyncConsumerDispatcher, the deliver activity's using scope closes at line 55, but OnCallbackExceptionAsync - the user-facing report of that same exception - fires at line 77, outside it. I reproduced that nesting in a probe: at the reporting call site Activity.Current has reverted to the enclosing activity and the deliver span is already stopped.

Costs nothing today, because the span event goes on inside the scope. But an application logging from its CallbackException handler, which is the normal thing to do with that event, would stamp the wrong SpanId or none, so it becomes a MUST violation the moment exceptions are logs. Fix is to move the reporting catch inside the activity scope. Not doing that in this PR: it is a scope change with no present-day symptom, so it wants its own test rather than riding along in a bug fix.

On the seam: RabbitMQ.Client has no ILogger and logs through EventSource, which is not a Logs API bridge. But the core already has the right pattern, since ContextExtractor and ContextInjector are settable static delegates the core calls and AddRabbitMQInstrumentation populates. An exception-recording delegate follows that precedent and keeps a logging abstraction out of the core. Adding the delegate is additive and safe on a stable API; the part with a deadline is what the OpenTelemetry package does with it, which is easier to settle before that package ships 1.0.0 (#1728).

All of this is now in #1992, and the review doc records the findings.

@lukebakken on the reference-library question: there is no .NET instrumentation to copy yet. OpenTelemetry.Instrumentation.AspNetCore 1.17.0 is the closest current-practice example and still uses span events, so we would be going first rather than following. @tmasternak, if you know of an instrumentation in any language that has implemented the opt-in, or of the OTel .NET SIG's plan for it, that would be the most useful thing to point us at.

[danielmarbach]

Thinking out loud here: So the callback approach is interesting because effectively the consumer interface is such a callback mechanism if I'm not mistaken.

[lukebakken]

@danielmarbach I pointed the OTel skills at this PR and followed the guidance. You can see that this PR is only part of #1979, so I feel OK merging it. Thoughts?