You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We know the N+1 thing for subscriptions, so when creating a catch-up subscription, we should use the overload, which doesn't have the stream positions, to subscribe to the beginning of the stream.
However, persistent subscriptions express different behaviour, which is also inconsistent with other clients (NodeJS, Rust), so when I subscribe without giving it a position, it will use Stream.End. Although I understand the intention to make persistent subscriptions behaving in message broker style, it is confusing.
The biggest issue for me is that it seems literally impossible to create a persistent subscription for an existing stream and get the very first event. When given Stream.Start, it will subscribe from 0+1, the second event.
The text was updated successfully, but these errors were encountered:
We know the N+1 thing for subscriptions, so when creating a catch-up subscription, we should use the overload, which doesn't have the stream positions, to subscribe to the beginning of the stream.
However, persistent subscriptions express different behaviour, which is also inconsistent with other clients (NodeJS, Rust), so when I subscribe without giving it a position, it will use
Stream.End
. Although I understand the intention to make persistent subscriptions behaving in message broker style, it is confusing.The biggest issue for me is that it seems literally impossible to create a persistent subscription for an existing stream and get the very first event. When given
Stream.Start
, it will subscribe from 0+1, the second event.The text was updated successfully, but these errors were encountered: