mirror of https://github.com/razor-ai/soup.git
1b85c2bc51
Run 30947949103 still lost windows/3.11 to the same 429, and the log says why the first cut did not help there. 1. The retry ladder was per repo. On that cell ALL SIX repos failed EVERY attempt — including the tiny fixtures every other cell fetched in under a second — so the Hub had cut the runner off for the duration, not throttled one hot file. Starting a fresh ladder on repo #2 the moment repo #1 gave up spent the budget faster without ever waiting the block out. Now there is one 6-minute budget for the list: each round retries only what is still missing, backing off 10s -> 60s. 2. Saving was restricted to the 3.11 cell to avoid three redundant uploads of the same key. The Hub cut off exactly that cell, so the two healthy Windows cells were forbidden from saving what they had and Windows ended the run with no cache at all — while Linux and macOS both saved. The gate optimised away the thing it was protecting. Any cell may save now; the losers of the race log "unable to reserve cache" and move on. Verified both paths against the extracted step: - happy: 6/6 warmed, warmed=all, 544 MB - failure (Hub unreachable): budget exhausted at 371s, backoff 10/20/40/60, six warnings, warmed=partial so the save step is skipped and no half-filled cache is frozen under the key. The step never raises, so the job still runs. The failure path is the half that was not exercised last time. |
||
|---|---|---|
| .. | ||
| ISSUE_TEMPLATE | ||
| workflows | ||
| FUNDING.yml | ||
| pull_request_template.md | ||