Problem

TailStream.TailEventHandlerObject, the object form a tailStream() handler may return, has no key for StreamDiagnostic events, although StreamDiagnostic is a member of TailStream.EventType. The runtime dispatches those events to the handler-object key streamDiagEvent (getHandlerName in src/workerd/io/trace-stream.c++), so in typed code

return { streamDiagEvent(ev) { ... } }

fails with TS2353 ('streamDiagEvent' does not exist in type 'TailEventHandlerType') while workerd calls exactly that key with an event of type "streamDiagnostic" whose diagnostic is { diagnosticsType: "droppedEvents", count }. A typed object handler cannot observe dropped tail events. The function form of the handler was already correct through the EventType default.

Origin: 23c0d98 (#5637) added the StreamDiagnostic interface, the EventType member and the C++ dispatch key together. In that PR's review the Event suffix was dropped from the TS interface and the type string (StreamDiagnosticsEvent → StreamDiagnostic), but the C++ handler key kept it and the handler-object key was never added.

Fix

Declare streamDiagEvent?: TailEventHandler<StreamDiagnostic> in types/defines/trace.d.ts and the four snapshot files, with a type test. Additive, types only; the key name follows the shipping runtime.

Alternative

streamDiagEvent is the one handler key that does not equal its event type (every other key does). If you consider the object-form keys not yet public, the cleaner fix is a C++ plus types rename of the key to streamDiagnostic, as 91f6875 did for attributes. I did not do that here because it would change behaviour for any handler already using streamDiagEvent; happy to switch if you prefer.

Tests

• bazel test //types:test/types/tail-stream-diag (new; asserts the key's handler type and that the handler parameter is TailEvent<StreamDiagnostic>; fails on the previous snapshot)
• bazel test //src/workerd/api/tests:tail-worker-test@ (runtime unchanged)
• just generate-types reproduces the snapshot edits byte for byte.
• Verified on the built binary with a .wd-test that the object handler's streamDiagEvent is called with diagnosticsType === "droppedEvents" and that a streamDiagnostic key is never called.

Related: #7846 touches the same trace.d.ts (different members); the two apply in either order.

Tested on macOS (Apple Silicon) only.