Skip to content
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

fix(worker): fix so that worker can be closed if Redis is down #2350

Merged
merged 1 commit into from
Jan 2, 2024

Conversation

manast
Copy link
Contributor

@manast manast commented Dec 22, 2023

Fixes #372

Copy link
Collaborator

@roggervalf roggervalf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

@roggervalf roggervalf force-pushed the fix/can-close-worker-if-redis-down branch from 1f64edf to ce0c6c9 Compare December 31, 2023 05:33
@roggervalf roggervalf merged commit 888dcc2 into master Jan 2, 2024
11 checks passed
@roggervalf roggervalf deleted the fix/can-close-worker-if-redis-down branch January 2, 2024 02:05
github-actions bot pushed a commit that referenced this pull request Jan 2, 2024
## [5.1.1](v5.1.0...v5.1.1) (2024-01-02)

### Bug Fixes

* **worker:** worker can be closed if Redis is down ([#2350](#2350)) ([888dcc2](888dcc2))
@SrdjanCosicPrica
Copy link

SrdjanCosicPrica commented Jan 10, 2024

Hi @manast @roggervalf

My project was on 5.1.0 before this, and after upgrading to 5.1.1, my jest tests started reporting

Jest did not exit one second after the test run has completed.

'This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.

Adding --detectOpenHandles does not show anything so I believe I'm closing everything as expected. I'm not sure where the issue is since it worked fine before this patch

Edit:
It seems that, when running a couple of tests at the same time (with --runInBand), one worker gets

this.blockingConnection.status === 'initializing'

when closing. So the client becomes null and it does not call disconnect on it

@manast
Copy link
Contributor Author

manast commented Jan 15, 2024

@SrdjanCosicPrica it would be great if you could isolate a test case where this happens so that we can reproduce it and fix it.

@SrdjanCosicPrica
Copy link

Ok I'll do my best to find some time to replicate it.
I solved my issue by adding a sleep of 10 ms Promise(resolve => setTimeout(resolve, 10)).

I'm using docker-compose during tests and my best guess is that the JS thread doesn't get enough time to establish a connection and mark it as ready before the test wants to complete. Adding the sleep gave enough time for the status to change.

@SrdjanCosicPrica
Copy link

Hey @manast I managed to reproduce it with minimal code that is close to how we are using it in the project where I discovered the issue.
https://github.com/SrdjanCosicPrica/bullmq-5.1.1-open-handles

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.

3 participants