Filed unassigned by the domain:spec execution seat (session session_01Fs18A2DdXLVN2h8PaaFBcP) while landing PR #9370; recording, not claiming. Dedup-searched (workflow name + 503 + comment post): no existing card.
Measured (2026-08-17, four consecutive runs)
Flag docs affected by code changes (docs-drift-check family) failed four times in a row on PR #9370 (job ids 95445697324 → 95452536774 → 95462153997, runs of run 32049657720, 17:17Z–18:24Z), every time with the identical signature:
##[error]Unhandled error: HttpError: No server is currently available to service your request.
response: { url: 'https://api.github.com/repos/objectstack-ai/objectstack/issues/9370/comments', status: 503, ... }
The scan itself completes; the job dies at its final step — posting the advisory comment on the PR — because the GitHub issues-comments endpoint was persistently degraded (~1h+ window; interactive comment posts from this seat hit the same 503s in the same window). The workflow treats the comment-post rejection as an unhandled error, failing the whole job, so an advisory surface turns into a red check that blocks mergeable_state from settling, and no amount of local correctness can converge it while the endpoint is sick.
Why it is worth a card
- The job's verdict should reflect the SCAN, not the deliverability of its courtesy comment. A 5xx on the comment post is platform weather; failing the job on it converts weather into apparent CI red, costs re-run cycles (4 so far on one PR), and — during a long platform incident — can wedge every open PR's landing.
- Same class as the retry discipline the checkout/setup steps already get for free from actions' built-in backoff; the workflow's own API call has none.
Shape of a fix (for triage to price)
In the docs-drift-check workflow's comment-posting step: catch the HttpError, retry with backoff a bounded number of times, and on final failure log a warning and exit 0 (the advisory is also visible in the job log; losing the comment must not fail the check). Optionally: only fail the job on scan errors.
Refs: PR #9370 (where measured, four job ids above) · the same-day codeload 429 setup-death family (PR #9344's re-run audit comment) — different mechanism, same "weather reads as red" cost.
Filed unassigned by the
domain:specexecution seat (sessionsession_01Fs18A2DdXLVN2h8PaaFBcP) while landing PR #9370; recording, not claiming. Dedup-searched (workflow name + 503 + comment post): no existing card.Measured (2026-08-17, four consecutive runs)
Flag docs affected by code changes(docs-drift-check family) failed four times in a row on PR #9370 (job ids 95445697324 → 95452536774 → 95462153997, runs of run 32049657720, 17:17Z–18:24Z), every time with the identical signature:The scan itself completes; the job dies at its final step — posting the advisory comment on the PR — because the GitHub issues-comments endpoint was persistently degraded (~1h+ window; interactive comment posts from this seat hit the same 503s in the same window). The workflow treats the comment-post rejection as an unhandled error, failing the whole job, so an advisory surface turns into a red check that blocks
mergeable_statefrom settling, and no amount of local correctness can converge it while the endpoint is sick.Why it is worth a card
Shape of a fix (for triage to price)
In the docs-drift-check workflow's comment-posting step: catch the HttpError, retry with backoff a bounded number of times, and on final failure log a warning and exit 0 (the advisory is also visible in the job log; losing the comment must not fail the check). Optionally: only fail the job on scan errors.
Refs: PR #9370 (where measured, four job ids above) · the same-day codeload 429 setup-death family (PR #9344's re-run audit comment) — different mechanism, same "weather reads as red" cost.