oss_12_onending_frozen#14
Conversation
The SDK froze the span (set _end_time and made attributes immutable) before invoking _on_ending, so any attribute/event/link a processor added inside the on_ending hook was silently dropped, violating the trace SDK spec which requires the span to remain mutable while OnEnding runs. Introduce an intermediate ending state: end() now records _end_time and marks the span as ending (tracking the ending thread's id) but leaves it mutable, runs _on_ending, then finalizes by freezing attributes and clearing the ending state. Mutators are permitted during this window only from the ending thread; after finalization, and from any other thread, they are rejected as before. ConcurrentMultiSpanProcessor previously fanned _on_ending out to its thread pool, which is incompatible with 'mutable only from the ending thread' and would race on the still-writable span. Its _on_ending now runs the underlying hooks sequentially on the ending thread, matching the documented contract that on_ending is called synchronously on the thread that ends the span.
|
🔒 Internal (dash0) — not for upstream.
|
|
📣 Public-facing draft — to be opened upstream in Title: Allow WhatIntroduce an intermediate "ending" state in WhyPreviously the span was frozen before TestingNew tests prove an attribute, event, and link added inside |
Closes #11
Fixes SpanProcessor.on_ending mutability (Linear OSS-12, finding T1): an intermediate 'ending' state lets on_ending mutate the span (from the ending thread) before it is frozen; ConcurrentMultiSpanProcessor.on_ending now runs synchronously on the ending thread. Attributes/events/links added in on_ending are no longer dropped.
Linear issue: https://linear.app/dash0/issue/OSS-12/t1-spanprocessoronending-runs-after-the-span-is-frozen-mutability-must