feat: current_trace_id() — read the caller's active trace id (RIUS-466) - #64
Draft
sudopower wants to merge 1 commit into
Draft
feat: current_trace_id() — read the caller's active trace id (RIUS-466)#64sudopower wants to merge 1 commit into
sudopower wants to merge 1 commit into
Conversation
sudopower
marked this pull request as draft
August 24, 2026 14:20
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
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.
The only SDK change the healing-agent demo needs. Part of RIUS-463, tracked as RIUS-466.
log_resolutionattributes a resolution to the run that produced it, so the healing agent needs its own trace id — not a trace it is investigating.Two details that matter
Uses OTel's own
format_trace_idrather than hand-rolled hex padding. Verified against the pinned opentelemetry-api 1.43.0 that it emits bare 32-hex with no0xprefix — older releases did prefix it, so rolling our own would have been a subtle format bug.span_context.is_validcovers both required cases in one check.INVALID_SPAN— whatget_current_span()returns with nothing active — has an all-zeros context, so the result isNonerather than a string of 32 zeros. A valid non-recording span (a propagated or sampled-out remote context) still returns its real trace id, which is the correct answer to "what trace is the caller inside".Worth knowing for callers: it returns
Noneunlessinit()has run, because with no provider OTel hands backINVALID_SPAN. Correct semantics, but a headless agent has to init before it can attribute anything.Verification
All four gates from CLAUDE.md:
The 6 skips are pre-existing (
test_instrumentation_registry.pyoutside an--all-extrasenvironment).Also verified live rather than only by unit test: inside a span it returns a real 32-hex id equal to the span's own context, nested spans report the same trace, and it is
Noneoutside any span and after the block exits.Version left at 0.12.0 and
CHANGELOG.mduntouched — release-please generates both from squashed PR titles, per CLAUDE.md.Unrelated drift noticed, deliberately not fixed here
CLAUDE.mdstill documents the pre-rename package (PyPIglassflow-ai, importglassflow,GLASSFLOW_env vars) whenmainisglassflow-rius/rius/RIUS_*. Andheartbeat.pyhand-rollsformat(trace_id, "032x")in two places that could now use the helper this PR adopts. Both left alone to keep the diff to one feature.