Add ThreadContext.invalidate() to flip record valid byte in place - #19
Merged
ivoanjo merged 1 commit intoAug 10, 2026
Merged
Conversation
When an SDK finishes a span, calling clearContext() on the current async-context frame detaches the ThreadContext only from that frame. Sibling and detached-continuation frames that already inherited the reference keep holding the same JS object — and with it the same underlying native record — so an out-of-process reader sampling those threads still sees the finished span's trace / span IDs as active. invalidate() writes 0 to the record's `valid` header byte in place, using the same volatile+atomic_signal_fence protocol the constructor and AppendAttributes() use for header bytes readers may race with. Because every async-context frame holding this ThreadContext reference observes the same shared record buffer, a single invalidate() drops the record out of scope for every such frame at once — readers see valid=0 and MUST ignore the record per OTEP-4947. The method is idempotent, safe under repeated calls, and orthogonal to attrs_data mutation: appendAttributes after invalidate is still observable in the record bytes, but readers honor the valid=0 flag regardless.
szegedi
marked this pull request as ready for review
August 6, 2026 14:52
umanwizard
approved these changes
Aug 6, 2026
Author
|
@umanwizard thanks for the approval! May I ask you to merge it for me? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
ThreadContext.invalidate(). Writes0into the record'svalidheader byte in place.Why
When an SDK finishes a span,
clearContext()on the current async-context frame detaches theThreadContextonly from that frame. Sibling and detached-continuation frames that already inherited the reference keep holding the same JS object (and with it the same underlying native record) so if one of those gets reactivated for some reason an eBPF reader sampling those contexts still sees the finished span's trace / span IDs as active. This is admittedly not a frequent concern, but it is still a good idea to invalidate the record when we know its span is ended.Every async-context frame holding the same
ThreadContextreference observes the same shared record buffer, so a singleinvalidate()drops the record out of scope for every such frame at once. Readers seevalid=0and MUST ignore the record per OTEP-4947.Test plan
./test/run-in-docker.sh) — 48/48 passing.