Repository navigation
feat: persist a finite automatic upload allowance - #71
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.
A watching upload worker could accept an unlimited queue, and restarting it provided no durable bound on how many uploads it could start. Add
--uploads-only --max-uploads Nto admit a finite cohort once across restarts. Failures and cancellation consume their slots; a terminal run keeps its place while detached work remains unresolved. Further videos stay saved in the queue. This limits admissions, not provider charges or total runtime.The runs root retains the fixed limit and immutable run identities. The limited worker has one owner, and supervisors share a dispatch lock so an unrestricted worker cannot bypass an installed policy. Missing or changed evidence stops admission. Manual runs keep their existing worker availability. Presence version 3 expresses manual-only scope, reads versions 1/2, and is safely ignored by older API readers; update the API and supervisors together.
The dashboard distinguishes a busy worker or exhausted upload allowance from a disconnected worker. Setup guidance no longer suggests that connecting another worker can reset the limit.
Validation: 1,524 Python tests passed locally; the final setup-message adjustment then passed all 32 submission tests. CI exposed an existing test race between detaching a stage and immediately finishing its run. The test now finishes in a second real agent turn after the stage settles, preserving the failed-stage and retained-log assertions; all 84 session/admission/control tests pass. Fourteen admin tests, TypeScript checking, formatting, Ruff, and an isolated production build passed. Independent review findings about manual availability and conflicting run selection were fixed and rechecked.
A real browser rehearsal submitted two local fixture videos through the production admin, API, SQLite store, and supervisor. Only the harness model boundary was inert: the first run recorded an explicit fixture failure, the second stayed queued at the limit, and restarting the worker preserved the exact admission ledger and queued state. No provider reconstruction was run, no dollar cap or visual-quality pass is claimed, and the existing live bottle run was untouched.
CI: all four jobs passed on
c3e2315, including 1,524 Python tests.