Competing Consumers - In version 3.3.0 Server with latest client 3.3.1

Hello All,

In using the Competing Consumers that was released recently in Event Store I have encountered an issue with events been processed multiple times.

The code below (for me at least) demonstrates the issue. If the ‘EventAppeared’ method does anything which takes more than a second or so to return the event will be picked up and processed again.

The sample code has been run against 3.3.0 EventStore server running in a Docker container and also natively in Windows. Removing the line Thread.Sleep in the code below will show each message being processed only once.

This seems to be an issue with events not being marked as ‘In Flight’ to me. Has anyone else encountered these issues?

using System;
using System.Threading;
using EventStore.ClientAPI;

namespace CompetingConsumerESConsole
class Program
static void Main(string[] args)
var eventListener = new EventListener();



public class EventListener
    public void StartReceiver()
        var connection = EventStoreConnection.Create(new Uri("tcp://admin:changeit@"));

        connection.ConnectToPersistentSubscription("bar", "foo",
           EventAppeared, SubscriptionDrop, autoAck: false);

        Console.WriteLine("connected succesfully");

    private void EventAppeared(EventStorePersistentSubscriptionBase eventStorePersistentSubscriptionBase,
       ResolvedEvent resolvedEvent)
        //Remove the line below, events are processed once only as expected
        Console.WriteLine($"Event Appeared with Id {resolvedEvent.OriginalEvent.EventId}");

    private void SubscriptionDrop(EventStorePersistentSubscriptionBase eventStorePersistentSubscriptionBase,
       SubscriptionDropReason subscriptionDropReason, Exception exception)
        Console.WriteLine($"{subscriptionDropReason} Event Deleted {exception.StackTrace}");



Messages retry when they time out. What are your settings on the
subscription for retries?

Awesome thanks Greg,

had missed that, I had created the subscription with the default values and it was set to zero by default.

From UI or?

It shouldn't default to 0 I think it defaults to 1 second if not set
IIRC the UI however may be providing its own defaults.

This hit me yesterday too. When creating from the UI, “Message Timeout” defaults to zero milliseconds.


Hi Greg,

sorry just spotted the update. This was occurring for me through the HTTP API