lane: babysit
Triggering example: over a single ~2.5 hour babysit session (2026-07-19/20), 5 independent Opus workers, each dispatched to a different PR with no shared context beyond their own PR, independently diagnosed the SAME two checks — do-not-merge / do-not-merge and pr-title / pr-title — as failing due to HttpError: No server is currently available to service your request (GitHub API 503) rather than any real problem with their PR's title or draft/label state. Affected PRs: #563, #564, #567, #568, #489 (spanning both draft and non-draft PRs, multiple branches, multiple authors' worth of content). One worker confirmed directly: PR title was valid Conventional Commits, labels were empty, yet the check still failed with the identical 503 stack in its own run log.
This isn't isolated to the babysit loop's own gh calls either — the same session separately saw a plain gh run view, a gh api comment PATCH, and pr_queue_snapshot.py's own reviews-fetch calls all hit transient 503s (see #574 and its comment thread) — but those come and go / retry-succeed. The do-not-merge/pr-title checks are different: they're failing consistently across a wide PR set over hours, which reads less like 'occasional GitHub API blip' and more like these two specific GitHub Actions workflows in this repo are calling something (the GitHub API, for draft/label/title lookups presumably) in a way that's non-resilient to transient 503s — i.e., these checks have no retry/backoff of their own, so any transient GitHub-side 503 during their run becomes a permanent FAILURE status on that check run, which then sits there failing until someone pushes a new commit to re-trigger it (and even then, it can immediately hit a fresh 503 again, as happened repeatedly this session).
Observed vs expected: observed — 5+ PRs sitting with 2 failing required-adjacent checks for hours, purely from unlucky 503 timing, no code content issue. Expected — the do-not-merge and pr-title GitHub Actions workflows should retry their own GitHub API calls (a few attempts with backoff) before reporting FAILURE, so a single transient upstream 503 doesn't permanently fail the check until the next push.
Category: bug (CI workflow resilience — likely in ci-workflows per the cross-repo ownership convention for reusable GitHub Actions execution, since this pattern spans multiple consuming PRs/branches in claude-code-plugins).
lane: babysit
Triggering example: over a single ~2.5 hour babysit session (2026-07-19/20), 5 independent Opus workers, each dispatched to a different PR with no shared context beyond their own PR, independently diagnosed the SAME two checks —
do-not-merge / do-not-mergeandpr-title / pr-title— as failing due toHttpError: No server is currently available to service your request(GitHub API 503) rather than any real problem with their PR's title or draft/label state. Affected PRs: #563, #564, #567, #568, #489 (spanning both draft and non-draft PRs, multiple branches, multiple authors' worth of content). One worker confirmed directly: PR title was valid Conventional Commits, labels were empty, yet the check still failed with the identical 503 stack in its own run log.This isn't isolated to the babysit loop's own
ghcalls either — the same session separately saw a plaingh run view, agh apicomment PATCH, andpr_queue_snapshot.py's own reviews-fetch calls all hit transient 503s (see #574 and its comment thread) — but those come and go / retry-succeed. Thedo-not-merge/pr-titlechecks are different: they're failing consistently across a wide PR set over hours, which reads less like 'occasional GitHub API blip' and more like these two specific GitHub Actions workflows in this repo are calling something (the GitHub API, for draft/label/title lookups presumably) in a way that's non-resilient to transient 503s — i.e., these checks have no retry/backoff of their own, so any transient GitHub-side 503 during their run becomes a permanent FAILURE status on that check run, which then sits there failing until someone pushes a new commit to re-trigger it (and even then, it can immediately hit a fresh 503 again, as happened repeatedly this session).Observed vs expected: observed — 5+ PRs sitting with 2 failing required-adjacent checks for hours, purely from unlucky 503 timing, no code content issue. Expected — the
do-not-mergeandpr-titleGitHub Actions workflows should retry their own GitHub API calls (a few attempts with backoff) before reporting FAILURE, so a single transient upstream 503 doesn't permanently fail the check until the next push.Category: bug (CI workflow resilience — likely in
ci-workflowsper the cross-repo ownership convention for reusable GitHub Actions execution, since this pattern spans multiple consuming PRs/branches inclaude-code-plugins).