Eventstore: Connections for Persistent Subscriptions are lost if the console debugged using VisualStudio

[AbdoDabbas]

Describe the bug
I have a project built using EventStore, NServiceBus, and Aggregates.Net (to link between the EventStore and NServiceBus).

I have two Endpoints, Domain: writes to the ES, and the other Read: listening to this event and writes to SQL.

I recognised that the Read endpoint depends on "Persistent Subscription" to listen to the events.

The issue is as the following:
If an event triggered from the Domain endpoint, and I'm doing an debug (breakpoint on one of the lines in the Read endpoint), I receive the event, but the connection to ES will be list, and no more events will be received until I restart the app again:
(Connections column on the row of the Read endpoint, will become zero)

To Reproduce
Steps to reproduce the behavior:
(Maybe these steps will

1. Use this sample to quickly launch the test case: https://github.com/charlessolar/TodoMVC-DDD-CQRS-EventSourcing
2. In Project Application->File Handler.cs -> Line: 46 (Events.Added)
3. Just add a breakpoint inside this handler, and wait for the event.
4. Observe the endpoint connection in the Subscriptions page in ES web app: http://localhost:2113/web/index.html#/subscriptions

Expected behavior
Should not lose the connection or re-connect if lost.

Actual behavior
Once connection lost will need to restart the app.

EventStore details

• EventStore server version: 20.6.1.0

• Operating system: Windows 10

• EventStore client version (if applicable): through the library Aggreagets.NET

[StevenBlair123]

I think it has been doing this since at least version 4. Never occurred to me to raise an issue for it!
It can be quite annoying.

[alexeyzimarev]

Both catch-up and persistent subscriptions are real-time. When you stop for debugging, the subscription heartbeat will not work and the subscription stops receiving events. It causes the subscription to drop and the library you use logs a message about it. The library also tries to resubscribe immediately and it doesn't work as your application is not running (stopped at your breakpoint), so it keeps failing. I guess it eventually gives up. You should really ask this in the library repository.

[AbdoDabbas]

@alexeyzimarev so how other developers debug their codes when using EventStore?

[gregoryyoung]

Increase your timeouts by a lot

On Mon, Mar 15, 2021 at 11:19 AM AbdoDabbas @.*>
wrote:

@alexeyzimarev https://github.com/alexeyzimarev so how other developers
debug their codes when using EventStore?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/EventStore/EventStore/issues/2854#issuecomment-799503789,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC5CWU4FNOL3ECIIC62VSLTDYQPBANCNFSM4ZFKT7XA
.

--
Studying for the Turing test

[charlessolar]

@gregoryyoung is right lol - when debugging I always set my timeouts to 5 minutes.

Set to more if you pause in the debugger for a long time.

The fundamental issue is the threads keeping the connection alive are suspended during debug. RabbitMq has the same issue - if you step in a RabbitMq app it'll lose connection to the server cause VS is incapable of letting certain threads keep running during debugging.

[alexeyzimarev]

The issue is that the library you use puts a lot of trust to a given subscription drop reason. UserInitiated could be triggered, among other things, by missing heartbeats. What I used to do is to still restart the subscription in case it was dropped with UserInitiated, but give it a bit or time (like 5 sec). If the app really wants to stop, it is usually enough time for the app to gracefully shutdown. Otherwise, it will resubscribe.

As for debugging, my subscriptions are usually quite simple as I find it odd to put any logic there. Tests, logs and just good critical look at the code resolves 90% of the cases.

Or, as Greg said, increase the heartbeat timeout in the connection settings.