oss_12_onending_frozen - #14
Conversation
|
🔒 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 |
|
This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment. |
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.
6099ec0 to
38431d5
Compare
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