Protocol differences between 4.1.* and 5.0.* on generated protobuf code.

EventStoreDB
#1

Greetings,

I got a weird behaviour between EventStore 4.1.* and 5.0.* and code generated by protoc (I don’t have this behaviour with my Haskell driver which doesn’t generate protobuf messages with protoc).

ReadStreamEvents command on $streams targetting 4.1.*: MessageNotInitialized.
Same but targetting 5.0.2 this time: Works as expected.

Note that I only got that behaviour with $streams stream. I tried with a bogus name like $foo or any regular stream’s name and got it working consistently on both servers.

I tried with my Haskell, my Rust and the official C# .NET Core clients. Both Haskell and .NET clients work consistently on both targetted version.

I spotted that behaviour with my Rust TCP driver that uses generated code from protoc. This is what the 4.1.* server returns to my rust client:

Exception raised: MessageNotInitialized { message: “ReadStreamEventsCompleted” }

``

The Rust client uses the latest protoc 3.10.0 and I was able to reproduce consistently that behaviour on both Ubuntu 18.04 and Mac OSX Mojave.

#2

I investigated some more and it turns out 4.1.* server returns invalid ResolvedIndexedEvents. In my case, A got numerous (58 out of 500 of the first batch alone) ResolvedIndexedEvents with event field undefined while link field is (I’m talking at protobuf level). In this setting, it’s a violation of the proto file I got from master.

message ResolvedIndexedEvent {
required EventRecord event = 1;
optional EventRecord link = 2;
}

``

I’m not having those issues with my Haskell and the official .NET Core clients. I don’t use protoc to generate the protobuf messages in my Haskell client but, I do for the Rust client. I don’t know how the .NET Core client generates its protobuf messages but it’s fair to assume that both Haskell and .NET Core protobuf code seem less strict than official protoc generator.

#3

Could it be possible those deleted events are causing me all the trouble? I don’t care about that database instance, I use it to test my clients.

Screenshot 2019-10-09 at 00.24.04.png
Screenshot 2019-10-09 at 00.24.04.png3272×1690 427 KB

My question is the following. Is it ‘safe’ to delete streams and use projections like $streams? In my situation, all I have to do to be able to read $streams (when stream deletions occurred) was altering the proto file (making the event field of ResolvedIndexedEvent optional).

Thanks for your time.

#4

Any thought on this?

#5

Hi Yorick,

We’re using unofficial java client ( https://github.com/msemys/esjc ) with ES 5.x and we receive linkTos to deleted events as eventMessage with null as the actual event. I believe that your problem might be related to the deleted events as ‘$streams’ are composed of links (linkTo) to the first event in a stream.

Hope this helps.

  • Karolis
#6

I went the same way and altered the protobuf files by making the event field optional:

I don’t know how esjc generated its protobuf, looks rust generator was extra zealous. Thank you for your input!

I’m creating a PR because the current protobuf declaration is misleading.