Skip to content
This repository has been archived by the owner on Sep 20, 2024. It is now read-only.

Ensure no reconnect happens after destroy() #434

Merged
merged 1 commit into from
Oct 12, 2016

Conversation

selfcontained
Copy link
Contributor

The purpose of this PR is to ensure if someone calls destroy() on their worker instance, it won't reconnect. Calling destroy() already cancels any pending reconnect attempts, but there's a small chance that the start.rtm api call was already issue, but hasn't received a response yet. In this case what happens is the worker closes out the current RTM connection and cancels any queued up reconnect attempts. It doesn't currently handle a case where the callback from the rtm.started api call comes back after destroy() was called.

I added a flag to track the state of if the worker has been destroyed - and then make sure to check that prior to creating the websocket connection for the RTM. This prevents the case described above.

We've run with this particular patch on a bot with about 60 teams connected and it's resolved issues they've had related to this bug (they would end up with 2 RTM connections to a team when trying to manually destroy a worker instance, and create a new one).

@mbrevoort
Copy link
Contributor

This is really a bug fix rather than an enhancement. It's affecting multiple Beep Boop users, would love to get this merged! 🙏

@anonrig
Copy link
Contributor

anonrig commented Oct 12, 2016

Nice catch!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants