Skip to content

runs: a reclaimed unit's further attempts go to the reclaim queue #83

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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Merged
rusholme merged 1 commit into from
Oct 5, 2026
Merged

runs: a reclaimed unit's further attempts go to the reclaim queue #83

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion system/runs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -206,7 +206,12 @@ terminal unit or replace its selection.
The run records a maximum attempts per unit, counting the first try
and every retry. The launcher retries; a Batch job runs its container
once. An attempt ending `transient` returns the unit to ready for
submission as a new attempt. Only code 75 and the approved
submission as a new attempt. Once one of a unit's attempts is lost to
a Spot reclaim, in the run or in a run it was seeded from, every
further attempt of that unit is submitted to the reclaim queue
(`RAPIDPIPE_BATCH_RECLAIM_QUEUE`) when that is set and differs from
the job queue; otherwise it goes to the job queue like any other
retry. Only code 75 and the approved
infrastructure failures listed in the [stage contract](stage-contract),
"Exit codes", are recorded `transient`. Exhausting the allowance fails
the unit. `lost` means the scheduler lost the job: unresolved
Expand Down