What we found
UnknownEvent is declared in src/common/interfaces/event.interface.ts (line 1015 on main today) but it is not a member of the exported Event union, and there is no UnknownEventResponse in the EventResponse union. The default branch of deserializeEvent in src/common/serializers/event.serializer.ts papers over the gap with a cast:
default:
return {
...eventBase,
event: (event as { event: string }).event,
data: (event as { data: Record<string, unknown> }).data,
} as Event;Effect
The cast hides the case from the compiler. A consumer that writes an exhaustive switch over event.event with an assertNever default compiles clean and throws at runtime on the first event type the SDK does not know. The Event union always trails the API, so this eventually happens to every such consumer.
Request
- Add
| UnknownEvent to the Event union.
- Add an
UnknownEventResponse interface and include it in the EventResponse union.
History
#1572 reported exactly this as its second item. It was closed as completed, but only the first item (abort signal plumbing) landed; the union is unchanged on main. The same class of failure keeps recurring with a different missing event type each time: #864, #1360, #1362, #1453, and #1685 (open). A typed UnknownEvent member turns each of those from a runtime failure into a compiler message.
What we found
UnknownEventis declared insrc/common/interfaces/event.interface.ts(line 1015 onmaintoday) but it is not a member of the exportedEventunion, and there is noUnknownEventResponsein theEventResponseunion. Thedefaultbranch ofdeserializeEventinsrc/common/serializers/event.serializer.tspapers over the gap with a cast:Effect
The cast hides the case from the compiler. A consumer that writes an exhaustive
switchoverevent.eventwith anassertNeverdefault compiles clean and throws at runtime on the first event type the SDK does not know. TheEventunion always trails the API, so this eventually happens to every such consumer.Request
| UnknownEventto theEventunion.UnknownEventResponseinterface and include it in theEventResponseunion.History
#1572 reported exactly this as its second item. It was closed as completed, but only the first item (abort signal plumbing) landed; the union is unchanged on
main. The same class of failure keeps recurring with a different missing event type each time: #864, #1360, #1362, #1453, and #1685 (open). A typedUnknownEventmember turns each of those from a runtime failure into a compiler message.