Skip to content

Cancel scheduled ControlConnection refresh if shutdown was called #440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

betalb
Copy link

@betalb betalb commented May 5, 2025

Store timeout, used to schedule refresh call, and clear it on shutdown.

Even though refresh call has check if shutdown was called, timeout itself may prevent nodejs process from shutting down until timeout is reached.

I have some concerns about test itself. Not sure that all the setup steps are required. But I've copied it mostly from previous test "should reconnect when all hosts go down and back up". What I wanted from the test:

  • spin up cluster
  • open control connection and ensure that it is live
  • stop cluster
  • call control connection shutdown
  • verify that refresh was not called

So the main test is pasted below, the rest is a boilerplate copied from other test.

// start spying on _refresh calls
cc._refresh = sinon.spy(cc._refresh);

cc.shutdown();

// wait for reconnectionDelay with 10% lag
await helper.delayAsync(parseInt(reconnectionDelay * 1.1, 10));

assert.ok(cc._refresh.notCalled);

Store timeout, used to schedule _refresh call, and clear it on
shutdown. Even though _refresh call has check if shutdown was called,
timeout itself may prevent nodejs process from shutting down until
timeout reached.
@SiyaoIsHiding
Copy link
Collaborator

Is this the only refresh timeout that needs to be canceled?
We probably should store all the refresh timeouts as controlconnection fields, and clear all of them at shutdown.

@betalb
Copy link
Author

betalb commented Jul 23, 2025

Need to refresh my memory. There is one more suspicious timeout created in _waitForReconnection, but I remember that I've spotted it as well. But, most likely, I've ignored it because it is small (2s).

I have a code that handles this timeout as well, but need to write a test for this particular case.

@betalb
Copy link
Author

betalb commented Jul 23, 2025

Ah, no, there was another reason why I decided not to handle timeout in _waitForReconnection explicitly. During shutdown newConnection event is emitted (with error) which triggers cleanup of this timeout. Probably small comment will make sense.

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.

2 participants