Support user span context propagation

[mar-cf]

No description provided.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

This PR propagates user span context to subrequest metadata and wires up the parent span ID in onset events for streaming tail workers.

1. [MEDIUM] userSpanContext is populated but never consumed. The new SubrequestMetadata::userSpanContext field is set in io-context.c++ but no downstream code (in server.c++ or elsewhere) reads it. If this is intentional scaffolding for a follow-up (or consumed in the internal repo), a brief comment explaining that would be helpful. Otherwise this is dead code.

2. [LOW] No tests for the onset parentSpanId behavior change. The change in tracer.c++ alters the spanId in the onset InvocationSpanContext from always-null to the trigger's span ID when a parent is present. This is a behavioral change to tail event output. Consider adding a test that verifies the onset event carries the correct parent span ID when a trigger context is available.

---

This review was generated by an AI assistant and may contain inaccuracies.

[ask-bonk]

This field is set in io-context.c++:1015 but I don't see any code that reads it from SubrequestMetadata. The downstream consumers (e.g., server.c++:3272 startSubrequest, the various startRequest implementations) pass the metadata through but never access userSpanContext.

Is consumption happening in the internal repo, or is this scaffolding for a follow-up? A brief comment here would help future readers understand the intent — e.g.:

Suggested change

	kj::Maybe<tracing::SpanContext> userSpanContext;
	// User Span Context for trace propagation. Consumed by [describe consumer].
	kj::Maybe<tracing::SpanContext> userSpanContext;

[ask-bonk]

This changes the onset event's top-level span ID from always nullId to the trigger's spanId when a parent context exists. This is a behavioral change to the tail event wire format — streaming tail workers will now see a non-zero span ID in onset events for triggered invocations.

Is this change covered by existing tests? I didn't find test coverage for the onset spanId value. Consider adding a test case (in the trace/tracer tests) that verifies the onset context carries the parent's span ID when a trigger is present, and nullId when it isn't.

[ask-bonk]

I've posted my review on PR #6407 with two findings:

1. [MEDIUM] The new userSpanContext field in SubrequestMetadata is populated but never consumed by any code in this repo — flagged as potential dead code or scaffolding for internal/follow-up work.

2. [LOW] The behavioral change in tracer.c++ (onset events now carry the trigger's span ID instead of always null) has no test coverage.

The SpanContext::clone refactor from member to static method and the rest of the code changes are mechanically sound with no safety or compatibility concerns.

github run