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


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.

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.

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.

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.

Any thought on this?

Hi Yorick,

We’re using unofficial java client ( ) 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

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.