Open
Conversation
worstell
force-pushed
the
eworstell/scheduler-priority-queue
branch
from
919d6cc to
a7037a5
Compare
| } | ||
| if q.maxCloneConcurrency > 0 && isCloneJob(job.id) && q.activeClones >= q.maxCloneConcurrency { | ||
| continue | ||
| if q.isPriority(job.queue) { |
Contributor
There was a problem hiding this comment.
Does this mean it will never take a non-priority job?
Contributor
Author
There was a problem hiding this comment.
no, they get added when there are no more priority jobs left - which is just the old behavior (FIFO).
basically the workers wake up, look to take their next job, if they come across a priority job they take it and break. otherwise the queue gets looped through in its entirety and then the first job taken (see lines below where index gets set if non-priority)
Add a priority-queues config option to the scheduler that accepts a list
of queue name prefixes. Jobs whose queue matches a priority prefix are
dequeued before non-priority jobs, while maintaining FIFO order within
each tier.
This allows operators to ensure that known important repositories (e.g.,
monorepos) are never starved by a flood of cold clone jobs for less
critical repos. The queue name is the upstream URL, so configuration is
straightforward:
scheduler {
priority-queues = ["https://github.com/org/monorepo"]
}
Co-authored-by: Amp <amp@ampcode.com>
Amp-Thread-ID: https://ampcode.com/threads/T-019d404e-21ec-723a-b211-c619925dd12e
worstell
force-pushed
the
eworstell/scheduler-priority-queue
branch
from
a7037a5 to
6f6b9e0
Compare
stuartwdouglas
approved these changes
Mar 30, 2026
alecthomas
reviewed
Mar 31, 2026
| MaxCloneConcurrency int `hcl:"max-clone-concurrency" help:"Maximum number of concurrent clone jobs. Remaining worker slots are reserved for fetch/repack/snapshot jobs. 0 means no limit." default:"0"` | ||
| SchedulerDB string `hcl:"scheduler-db" help:"Path to the scheduler state database." default:"${CACHEW_STATE}/scheduler.db"` | ||
| Concurrency int `hcl:"concurrency" help:"The maximum number of concurrent jobs to run (0 means number of cores)." default:"4"` | ||
| MaxCloneConcurrency int `hcl:"max-clone-concurrency" help:"Maximum number of concurrent clone jobs. Remaining worker slots are reserved for fetch/repack/snapshot jobs. 0 means no limit." default:"0"` |
Collaborator
There was a problem hiding this comment.
BTW unrelated, but can we get rid of the tight coupling between cloning and the scheduler? We should be able to build an abstraction here, similar to what you've done with this.
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
3 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.
Summary
Add a
priority-queuesconfig option to the scheduler. Jobs whose queue name matches a priority prefix are dequeued before non-priority jobs, while maintaining FIFO order within each tier.Motivation
When cachew is under load (e.g., a burst of cold clone requests), important repositories like monorepos can get stuck behind a queue of less critical work. This change lets operators ensure high-value repos are always serviced first.
Configuration
Queue names are upstream URLs, so the values are intuitive. Multiple prefixes can be specified.
Design
The
takeNextJobscan does a single pass: it tracks the first eligible non-priority job as a fallback, but immediately selects the first eligible priority job if found. This preserves the existing O(n) scan cost with no additional data structures.Existing behaviour is unchanged when
priority-queuesis empty (the default).