There is a discrepancy between handling events (creating message consume context) from EventStoreDB CatchUp subscriptions and Persistent subscriptions, which might be unintentional.
For persistent subscriptions, the original event stream name is not respected for subscriptions based on projected streams like "$ce-" or "$et-". In this case (let's assume we have a subscription on "$et-RoomBooked" projected stream) instead of the event stream name like "Booking-12345" the context (ctx.Stream) has the projected stream name "$et-RoomBooked".
CatchUp subscriptions do not have this issue. They provide the original stream name from the event.
If we look at the code in the PersistentSubscriptionBase class, the context is created taking the re.OriginalStreamId value.
IMessageConsumeContext CreateContext(ResolvedEvent re, CancellationToken cancellationToken) {
var evt = DeserializeData(
re.Event.ContentType,
re.Event.EventType,
re.Event.Data,
**re.OriginalStreamId,** // "$et-RoomBooked"
re.Event.Position.CommitPosition
);
But in the StreamSubscription class, the same logic uses the re.Event.EventStreamId, which holds the current event stream name.
IMessageConsumeContext CreateContext(ResolvedEvent re, CancellationToken cancellationToken) {
var evt = DeserializeData(
re.Event.ContentType,
re.Event.EventType,
re.Event.Data,
**re.Event.EventStreamId,** // "Booking-12345"
re.Event.EventNumber
);
Expected behavior
Both subscription types should provide the same stream name (original event stream name).
There is a discrepancy between handling events (creating message consume context) from EventStoreDB CatchUp subscriptions and Persistent subscriptions, which might be unintentional. For persistent subscriptions, the original event stream name is not respected for subscriptions based on projected streams like "$ce-" or "$et-". In this case (let's assume we have a subscription on "$et-RoomBooked" projected stream) instead of the event stream name like "Booking-12345" the context (ctx.Stream) has the projected stream name "$et-RoomBooked". CatchUp subscriptions do not have this issue. They provide the original stream name from the event.
If we look at the code in the PersistentSubscriptionBase class, the context is created taking the re.OriginalStreamId value.
But in the StreamSubscription class, the same logic uses the re.Event.EventStreamId, which holds the current event stream name.
Expected behavior Both subscription types should provide the same stream name (original event stream name).