Repository navigation
Retry the registry record on transient failures - #151
Conversation
The registry record step made one POST and failed the job on any answer
other than 200 or 409. The registry validates a record by fetching each
asset's signature and certificate files from the CDN, and a transient
503 there comes back as HTTP 400 with the upstream status in its
message:
{"code":3, "message":"asset \"windows-amd64-msi\" detached signature
files are required: fetch certificate: GET .../name_v1.2.3_windows_amd64.msi.cert
returned HTTP 503"}
A release that was fully published then needed a manual re-run of the
failed job, and a false "release failed" notification went out.
The POST now retries, re-sending the same body after 10, 20, 40 and 80 s,
on a transport error, a 5xx, a 429, or a 400 whose message reports an
upstream 5xx. Any other 4xx is final on the first attempt. The response
handling, the flags and the 30 s per-request timeout are unchanged.
Follow-up outside this repository: the registry API should answer 503 for
a failed validation fetch instead of 400; once it does, the body check
here can go.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Superseded — see the current review report for commit
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Superseded — see the current review report for commit
|
A connection dropped after the headers arrived surfaced as a read error and ended the record attempt at once, while a drop before the headers was retried. Both are the same transient failure; the read error now falls through to the retry path, and after the last attempt is reported with the attempt count like a failed request. Tests add the transport cases: a drop before the headers then 200, a body cut after the headers then 200, and five drops in a row ending in the "after 5 attempts" error. Restoring the early return fails only the body-cut case. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Superseded — see the current review report for commit
|
General PR Review: Retry the registry record on transient failuresBlocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0 Review SummaryThis PR wraps the registry record POST in Security IssuesNone found. Correctness IssuesNone found. SuggestionsNone. Resolved prior findings
Reviewed commit: |
2 participants
The registry record step made one POST and failed the job on any answer other than 200 or 409. The registry validates a record by fetching each asset's signature and certificate files from the CDN, and a transient 503 there comes back as HTTP 400 with the upstream status in its message:
A release that was fully published then needed a manual re-run of the failed job, and a false "release failed" notification went out.
The POST now retries, re-sending the same body after 10, 20, 40 and 80 s, on a transport error, a 5xx, a 429, or a 400 whose message reports an upstream 5xx. Any other 4xx is final on the first attempt. The response handling, the flags and the 30 s per-request timeout are unchanged.