InMemoryEventStore.getStreamIdFromEventId derives the stream id with eventId.split('_')[0], which returns the empty string for any event id belonging to the standalone GET stream (its stream id _GET_stream starts with an underscore, so generated ids look like _GET_stream_<uuid>).
As a result, resuming the standalone stream with a Last-Event-ID never works with the shipped example store: replayEventsAfter replays nothing and returns '', and the transport registers the successor stream under the key '' instead of _GET_stream. All stored and future standalone notifications are then silently dropped while the client sits on a healthy-looking keep-alive'd stream.
Pre-existing (the id format and the split predate the keep-alive work). Fix is to derive the stream id from the last separator instead of the first, or to keep an explicit eventId-to-streamId map in the store. Affects the example store on both main and v1.x; regression tests built on this store also exercise the wrong key.
InMemoryEventStore.getStreamIdFromEventIdderives the stream id witheventId.split('_')[0], which returns the empty string for any event id belonging to the standalone GET stream (its stream id_GET_streamstarts with an underscore, so generated ids look like_GET_stream_<uuid>).As a result, resuming the standalone stream with a
Last-Event-IDnever works with the shipped example store:replayEventsAfterreplays nothing and returns'', and the transport registers the successor stream under the key''instead of_GET_stream. All stored and future standalone notifications are then silently dropped while the client sits on a healthy-looking keep-alive'd stream.Pre-existing (the id format and the split predate the keep-alive work). Fix is to derive the stream id from the last separator instead of the first, or to keep an explicit eventId-to-streamId map in the store. Affects the example store on both main and v1.x; regression tests built on this store also exercise the wrong key.