Closed PhotoAtomic closed 2 years ago
There is a draft PR under discussion: https://github.com/EventStore/EventStore/pull/3459. If it gets merged, then this should be available in one of the upcoming database versions. It should return position as long as the event wasn't added in the transactions (that shouldn't be an issue as long as you didn't append it through TCP client using transactions).
WOW! that will be great! I'm not using transaction so this improvement will be very beneficial for my code, I can't wait to try it!
Describe the bug As for discussion reported in the forum here:
the result of client.ReadStreamAsync is a ReadStreamResult object but all the ResolvedEvent it contains, have the same value 18446744073709551615 for the field Position of Event, which is wrong (and useless), as agreed in the forum discussion linked above
To Reproduce ` [TestMethod] public async Task RetrievedEventShouldProvideTheirRealPosition() {
`
Expected behavior
the event in the result[...].Event.Position should not always be Position.End, but instead should contain the real position of the event in the "All" stream
Actual behavior it appears that the client always returns an hard coded Position.End value for the Position field of the Event instead of their real position in the database's All stream
EventStore details
EventStore server version: 21.10.2.0 (and all the previous versions I've tested)
Operating system: Windows 10
EventStore client version (if applicable): gRPC client 22.0.0 (and all the previous versions I've tested)
Additional context As discussed with @yves.lorphelin and @alexey.zimarev, this is a wrong behavior and the system is not intended to work in this way. The system should instead provide the real Position of each event returned. It also appear that the database team is aware of this and have fixed the issue at the database side in the 21 version (see pull request as for @yves.lorphelin post) but the client still doesn't report the correct value I'm unable to determine if the issue is still at the database side, or if it is at the client side, or if maybe it is just a lack of documentation and there is a way to obtain this value.
To note that other methods (for example the AppendToStreamAsync and also SubscribeToAllAsync with regex filter, and others...) are able to retrieve the correct value.
Having the ability to know at client side the real Position of each event opens very useful possibility, for example an absolute ordering of events that came from different streams, and also to apply some nice optimization in the code. not having this field correctly populated prevents these or requires very complex and not efficient workarounds.