Repository navigation
nri-observability: report request id as request.id field on Honeycomb spans - #162
Merged
waj merged 1 commit intoAug 17, 2026
Conversation
… spans The Honeycomb reporter minted a fresh UUID at report time for trace.trace_id and discarded the request id it was handed, so the request id shown to users (e.g. the "Error code" on branded error pages) and propagated via X-Request-ID was not findable in Honeycomb. Keep trace.trace_id semantics unchanged (using the request id as trace id without distributed tracing would create same-trace_id spans across services with no parent links) and instead stamp the request id on every span as request.id, so traces can be looked up by it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Fixes PD-4073
Problem
The branded error pages added in NoRedInk/NoRedInk#55151 display an "Error code" (the per-request UUID from
Platform.requestId), but that code can't be found in Honeycomb: the Honeycomb reporter mints a separate random UUID at report time fortrace.trace_idand discards the request id it is handed. The request id reaches Bugsnag and file logs, but Honeycomb only sees it incidentally ashttp.headers.x-request-idwhen the client sent that header — never for browser traffic.Fix
Keep
trace.trace_idsemantics unchanged (using the request id as trace id without real distributed tracing would create same-trace_id spans across services with no parent links, and span ids<uuid>-<index>would collide). Instead, thread the request id intomakeSharedTraceDataand stamp it oninitSpanas arequest.idfield, so it appears on every span of the trace and traces can be looked up withrequest.id = <error code>. Skipped when the request id is empty (Platform.silentHandler/ tests).Also bumps nri-observability to 0.4.1.0 with a CHANGELOG entry.
Testing
golden-results-9.8andgolden-results-9.10(they were byte-identical before, so the regenerated 9.8 outputs were copied across).Accept: text/htmland query the dataset forrequest.id = <displayed error code>.This PR was written with AI assistance.
🤖 Generated with Claude Code