feat(WO-1143): determine Onset's SpanKind, serialize to JS

[repository]

Determine the appropriate SpanKind for an Onset depending on the type of info provided

If not explicitly overwritten in WorkerTracer::setEventInfoInternal, Onset's SpanKind will default to Server

Please also see:
#6471

Handler type	SpanKind	Why
FetchEventInfo	SERVER	Worker receives and responds to an inbound HTTP request
JsRpcEventInfo	SERVER	Worker receives and responds to an inbound RPC call
ConnectEventInfo	SERVER	Worker receives an inbound TCP connection
TraceEventInfo	SERVER	Worker receives tail events to process (tail worker)
HibernatableWebSocketEventInfo	SERVER	Worker receives a WebSocket message to handle
CustomEventInfo	SERVER	Worker receives a custom event (catch-all for other handler types)
ScheduledEventInfo	CONSUMER	Worker invoked by a cron trigger, consuming a scheduled task
AlarmEventInfo	CONSUMER	Worker invoked by a DO alarm, consuming a previously scheduled alarm
QueueEventInfo	CONSUMER	Worker invoked to process messages from a queue
EmailEventInfo	CONSUMER	Worker invoked to process an inbound email from a mailbox

[ask-bonk]

Good. The spanKindToString function at line 145 is inside the anonymous namespace (lines 16-969), which is correct -- it's a file-local helper.

Let me verify the full picture of the review. The changes are:

1. tracer.c++: Logic to derive SpanKind from EventInfo type in setEventInfoInternal -- correct, passes it to the Onset constructor.
2. trace-stream.c++: String constants for SpanKind values + spanKindToString helper + serialization of onset.spanKind into JS object -- correct.
3. types/defines/trace.d.ts: TypeScript types for SpanKind and spanKind on Onset -- correct.
4. types/generated-snapshot/: Updated snapshots -- consistent with defines.
5. Test files: Updated expected JSON strings to include "spanKind" field with correct values per event type.

Everything looks correct and consistent. The implementation is straightforward, the test coverage is thorough (existing tests updated to verify the new field), and there are no backward compatibility concerns since:

• The capnp schema changes (adding new fields) are wire-compatible
• TailStream is still an experimental API
• No compat flag is needed for new fields on experimental APIs

LGTM

github run