The current SSE API models event IDs as non-zero integers. This appears to be more restrictive than the SSE specification, which describes the value as an "event ID string". See https://html.spec.whatwg.org/dev/server-sent-events.html#the-last-event-id-header
The current API prevents valid SSE use cases such as:
- UUIDs
- Opaque cursor tokens
- Composite identifiers (e.g.
stream-123:456)
- Explicitly using
0 as an event ID (useful when talking about offsets into a stream)
Would it be possible to add support for strings? This would more closely match both the SSE specification.
I'm happy to submit a PR if a project maintainer could advise an approach. My instinct is to add an IDString string field alongside ID int and mark ID as deprecated. The string value would take precedence over the integer value if both are present. If having two separate fields is not desirable, an as an alternative, we could relax ID type to any and perform stringification dynamically, but I'd argue the two-field approach is clearer.
cc @danilvpetrov
The current SSE API models event IDs as non-zero integers. This appears to be more restrictive than the SSE specification, which describes the value as an "event ID string". See https://html.spec.whatwg.org/dev/server-sent-events.html#the-last-event-id-header
The current API prevents valid SSE use cases such as:
stream-123:456)0as an event ID (useful when talking about offsets into a stream)Would it be possible to add support for strings? This would more closely match both the SSE specification.
I'm happy to submit a PR if a project maintainer could advise an approach. My instinct is to add an
IDString stringfield alongsideID intand markIDas deprecated. The string value would take precedence over the integer value if both are present. If having two separate fields is not desirable, an as an alternative, we could relaxIDtype toanyand perform stringification dynamically, but I'd argue the two-field approach is clearer.cc @danilvpetrov