Repository navigation
feat: add persistent priority scheduling - #5
Merged
Merged
Conversation
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
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
Adds persistent priority-aware scheduling to the distributed task processor.
HIGH,NORMAL, andLOWtask prioritiesNORMALScheduling policy
Queued jobs are ordered by:
A waiting job rises one effective priority level every configured aging interval, which defaults to 60 seconds. Effective priority is capped at
HIGH.Only the original priority and submission sequence are persisted. Effective priority is calculated when scheduling and is not stored.
Scope boundaries
Priority affects queued-job ordering only.
This change does not add:
Worker selection, overload control, deadlines, cancellation, retries, stale-result rejection, and idempotency retain their existing behavior.
Priority is part of idempotent submission identity. Reusing an idempotency key with a different priority produces a conflict, while omitted priority and explicit
NORMALare equivalent.Persistence and compatibility
SQLite migration adds:
priority, defaulting toNORMALsubmission_sequence, defaulting to0for legacy recordsNew submissions receive unique, monotonically increasing sequences that survive coordinator restarts.
Legacy records remain readable. Because historical submission order was not previously stored, ordering among legacy records sharing sequence
0is best-effort using creation time and job ID.Legacy
SubmitJobandJobSnapshotmessages without priority remain compatible.Testing
Command:
./mvnw clean test failsafe:integration-test failsafe:verifyResults:
Coverage includes priority ordering, deterministic FIFO behavior, starvation prevention with a controlled clock, retry retention, restart recovery, sequence continuity, SQLite migration, protocol compatibility, CLI validation, and idempotency conflicts.