Skip to content

sentry/execution: fix websocket subscription reconnect - #882

Open
damilolaedwards wants to merge 1 commit into
ethpandaops:masterfrom
damilolaedwards:fix/mempool-websocket-reconnect
Open

sentry/execution: fix websocket subscription reconnect#882
damilolaedwards wants to merge 1 commit into
ethpandaops:masterfrom
damilolaedwards:fix/mempool-websocket-reconnect

Conversation

@damilolaedwards

Copy link
Copy Markdown

Summary

The retry wrapper around the mempool websocket subscription waited on a context that was never canceled when the subscription itself dropped, only when the whole watcher shut down. So after any connection blip the subscription silently stopped receiving new pending transactions and never reconnected, despite the retry loop looking like it was still running.

subscribeToNewPendingTransactions now returns a channel that closes when its processing goroutine exits, and the retry loop waits on that instead of on an unrelated context. It also derives its subscription context from the retry loop's own context, so cancellation still propagates correctly on shutdown.

This made an existing bug reachable that was previously masked by the subscription never actually reconnecting: subscriptionCancel is written each time a new subscription is established and read from Stop, with no synchronization between them. Added a mutex around it.

Test plan

  • go build ./...
  • go test ./pkg/sentry/execution/... -race
  • New test simulates a dropped connection and asserts a second subscription attempt follows within a few seconds

The retry wrapper around the mempool websocket subscription waited on
a context that was never canceled when the subscription itself
dropped, only when the whole watcher shut down. So after any
connection blip the subscription silently stopped receiving new
pending transactions and never reconnected, despite the retry loop
looking like it was still running.

subscribeToNewPendingTransactions now returns a channel that closes
when its processing goroutine exits, and the retry loop waits on that
instead of on an unrelated context. It also derives its subscription
context from the retry loop's own context, so cancellation still
propagates correctly on shutdown.

This made an existing bug reachable that was previously masked by the
subscription never actually reconnecting: subscriptionCancel is
written each time a new subscription is established and read from
Stop, with no synchronization between them. Added a mutex around it.

Included a test that simulates a dropped connection and asserts a
second subscription attempt follows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant