Hayley Campbell

The nodes update their gossip based on the gossip received from other nodes in the cluster. It's possible that this can get out of date if a gossip to/from one...

Are you possibly restarting Event Store between writing the two events, or batching the two writes together? The cache of existing event Id's is empty on restart, and with batching,...

Thanks for the suggestion @StevenBlair123, we're discussing this internally Just to clarify, this issue is only for setting metadata on result streams created by the projections, not for emitted stream....

Thanks! We're discussing this feature internally and will let you know what we decide

Hi @StevenBlair123, we haven't made a decision on this yet. It's also worth noting that if we do decide to add it, it'll likely only be added to the interpreted...

Hi @tautvydasversockas Are you seeing both events when you read the stream afterwards? And are you appending with an expected version?

What use case are you testing or running into? Idempotent writes are meant to be used to ensure retries of writes don't result in the same event written twice. We...

I think that allowing nodes to truncate without going offline would cut back on verification running unnecessarily. We should consider this when working on LogV3

The Persistent Subscription NAK and Retry logs should also be looked at as part of this: https://github.com/EventStore/EventStore/issues/2967

As a further note to this - Since DEBUG logs are often disabled, we want to make sure that we can diagnose most common issues after the fact based purely...