feat(replays): Record segment names that occur during replay#21851
Conversation
size-limit report 📦
|
mjq
requested review from
Lms24,
logaretm and
mydea
and removed request for
a team
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8f45b63. Configure here.
| const segmentName = spanJSON.name; | ||
| if (traceId && segmentName) { | ||
| addSegmentDetailsToContext(replay, traceId, segmentName); | ||
| } |
There was a problem hiding this comment.
Empty segment name drops trace
Medium Severity
Under span streaming, replay no longer records a trace_id when the segment span’s streamed name is empty. The previous afterSegmentSpanEnd handler still added trace IDs for sampled segment spans regardless of name, so unnamed segments can lose trace_ids on replay events while other linked data still expects them.
Reviewed by Cursor Bugbot for commit 8f45b63. Configure here.
logaretm
left a comment
logaretm
left a comment
There was a problem hiding this comment.
Got some m/q comments in there. Also would be great to lock down the static spans (non-streaming) by asserting segmentNames in handleAfterSendEvent.test.ts. The afterSendEvent transaction path is writing names untested as far as I can tell.
|
|
||
| const traceId = spanJSON.trace_id; | ||
| const segmentName = spanJSON.name; | ||
| if (traceId && segmentName) { |
There was a problem hiding this comment.
m/q: This couples the trace_id to the segment name: if a sampled segment span has a valid trace_id but an empty name, we now record neither. I think bugbot flagged this, is this intended?
AFAIK, Since traceIds and segmentNames are independent sets with independent caps and dedup, there's no benefit to gating them together, it just drops trace_ids for nameless segments.
Suggest recording the trace_id whenever present and moving the empty-name guard into addSegmentDetailsToContext.
If the coupling is intentional, a comment explaining why would help.
| const traceId = event.contexts?.trace?.trace_id; | ||
| if (traceId) { | ||
| addTraceIdToContext(replay, traceId); | ||
| if (traceId && event.transaction) { |
There was a problem hiding this comment.
m/q: This was if (traceId) before, so a transaction event with a trace_id but no transaction name will no longer record its trace_id.
event.transaction is optional, so this is a behavioral change for nameless transactions. I think we can decouple setting a traceId from setting a segmentNames so that both enrich the replay independently where possible.
What do you think?
2 participants
Record a new
segment_namesfield on replay events.This will be used in the product on the Transaction Summary page to fetch replays related to a particular named transaction.
This sidesteps our current issue under span streaming where Replay's
buffermode leads tosentry.replay.idattributes often pointing to missing Replays, which broke the assumption that a "query spans by segment name to get replay IDs, then query replays with those IDs" query flow will return a usable number of results.Closes REPLAY-937.