Prevent scanning for worker queues on init#269
Merged
Conversation
Connecting to the DB or Redis on init might be problematic if that connection / query can't be quickly executed, or raises an exception / times out, because it could crash the reporter and with it the whole process. This eliminates the init methods, and leave the queue discovery to the collection time, which already runs inside the reporter thread, and are wrapped in proper exception handling. Another benefit of leaving this to the collection time is that we should have faster init/boot time for GoodJob & SolidQueue adapters. One potential drawback is that we won't auto-discover queues that don't have a pending/enqueued job, until they actually do, so they may not show up initially. But it should not be a problem in terms of autoscaling behavior.
This was referenced Mar 4, 2026
This guarantees we'll report all known queues with every collect, but instead of eagerly loading it on init, we're doing it on first collect when the queues list is empty.
carlosantoniodasilva
changed the title
carlosantoniodasilva
added a commit
to judoscale/judoscale-python
that referenced
this pull request
Mar 5, 2026
Connecting to the DB or Redis on init might be problematic if that connection / query can't be quickly executed, or raises an exception / times out, because it could crash the reporter and with it the whole process. This eliminates the scanning on init, and leave the queue discovery to the collection time, which already runs inside the reporter thread, and are wrapped in proper exception handling. Ref.: judoscale/judoscale-ruby#269
carlosantoniodasilva
pushed a commit
that referenced
this pull request
Mar 5, 2026
## [1.13.2](v1.13.1...v1.13.2) (2026-03-05) ### Bug Fixes * Prevent scanning for worker queues on init ([#269](#269)) ([345c0e2](345c0e2)) --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Connecting to the DB or Redis on init might be problematic if that connection / query can't be quickly executed, or raises an exception / times out, because it could crash the reporter and with it the whole process.
This eliminates the init methods, and leave the queue discovery to the collection time, which already runs inside the reporter thread, and are wrapped in proper exception handling.
Another benefit of leaving this to the collection time is that we should have faster init/boot time for GoodJob & SolidQueue adapters.
Closes #267
Closes #268
Ref.: judoscale/judoscale-python#131