SubscribeToStreamAsync will start with the next event after a given position

[alexeyzimarev]

Describe the bug
SubscribeToStreamAsync with StreamPosition.Start will start from the second event in the stream

When subscribing from StreamPosition.Start, the first event delivered to eventAppeared will be the second event in the stream.

To Reproduce
Steps to reproduce the behavior:

1. Append 10 events to the stream
2. Subscribe to the same stream from Start
3. Get nine events back

Expected behavior
Subscription delivers all events when using StreamPosition.Start.

Actual behavior
Subscription starts with the second event in the stream.

EventStore details

• EventStore server version: 20.6.1

• Operating system: macOS

• EventStore client version (if applicable): 20.6.1

Additional context
https://github.com/alexeyzimarev/EsdbSubscriptionBug

[alexeyzimarev]

Following @thefringeninja advice, the workaround for reading from the start is to use the overload without the position. It indeed starts from the beginning of the stream.

[alexeyzimarev]

Updated the description.

[kaancfidan]

We have experienced this issue as well. Since we needed to also use a starting position in some cases we had to use the parameterless overload when a starting point is not specified and subtract 1 and use the bugged overload otherwise.

Needless to say, we would appreciate if this bug is fixed soon as it's a fundamental problem in gRPC client.

[thefringeninja]

This is by design - subscribing is an exclusive operation. If you have no checkpoint, please user the overload that does not take a StreamPosition.

https://developers.eventstore.com/clients/dotnet/generated/v20.6.1/subscribing-to-streams/#subscribing-to-a-stream

[kaancfidan]

This is by design - subscribing is an exclusive operation. If you have no checkpoint, please user the overload that does not take a StreamPosition.

https://developers.eventstore.com/clients/dotnet/generated/v20.6.1/subscribing-to-streams/#subscribing-to-a-stream

I don't think off-by-one errors are by design and the behavior is different than the old TCP client.

[dariogriffo]

This is extremely confusing and should be properly documented. Wuth the concept of start as a position is natural to think the start of the stream is the event number 0, not whatever the underlying limitation of the implementation of the event store.
Also this adds overhead on every client that consumes the library:

If(we-dont-have-processed-events)
    Subscribe()
else
    Subscribe(position)

Is way more natural just do

var lastPosition = GetLastPosition()
Subscribe (lastPosition)

[ylorph]

this has been fixed in version 22.0.0 of the client,
you can use FromAll.Start, FromStream.Start to achieve the desired behaviour.
More details in this PR #188