You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 19, 2026. It is now read-only.
Repository navigation
Commit 4b24a5f
Browse filesBrowse the repository at this point in the historyBrowse files
scheduler: detect job stuck queued while its parent run has completed
A workflow_job sometimes stays status=queued on GitHub forever after
its parent workflow run terminates -- e.g. when a sibling fails fast
or the run is cancelled before scheduling reaches the job. The
scheduler used to keep trying to provision a runner for those jobs
indefinitely.
sync_jobs now probes the parent run when GitHub still reports the job
queued. If the run is completed, mark the job failed with a v1 record
that captures the run's conclusion. The probe is gated on
JobStuckQueuedMinAge (10 min in internal/constants.go) so the normal
freshly-queued window is not charged for an extra GitHub API call
every reconcile cycle.
Side fixes hit while wiring this up:
- internal.FailureInfo gained a Message field so v1 rows
({version:1, message:"..."}) match the legacy on-disk shape
templates_test.go has been pinning all along. The two existing v1
callsites in sync_jobs (installation 404, job 404) were stuffing
the human message into the typed Reason field; switch them to
Message. Document the v1 vs v2 split in the struct doc.
- Extend internal.GHJob with the run_id field GitHub already returns,
and add GHRun + GitHubClient.GetRunInfo for the new probe.
- Wire OnGetRunInfo through FakeGH for tests.
https://claude.ai/code/session_01Vda2TpwJnGYRYuw1Xg46Da
0 commit comments