Repository navigation
fix: stop reporting healthy dispatches as failures - #13
Merged
Merged
Conversation
Creating a job polled the workflow runs list to confirm the dispatch produced a run. The list lags the run by longer than the wait, so runs that had already started were reported missing, and the verdict was written to the job branch — which the runner was about to push its own "running" commit to. Its push was rejected and the build died. Job mslrae6q-587ae96c was killed this way eleven seconds after its run started normally. The dispatch call itself still surfaces anything GitHub rejects. A run that never starts is already covered by the studio's stall detection, which offers a restart after five minutes and writes nothing until asked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185X6NPgr1v2jXVVDnK5DmZ
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What went wrong
Creating a job polled the workflow runs list for 7.5 seconds to confirm the dispatch had produced a run, and wrote a failure verdict to the job branch if it saw none. Both halves were wrong.
The list lags. Job
mslrae6q-587ae96cshows it exactly:So the check did not merely cry wolf. Its side effect killed a run that was working, because the branch it wrote to is the one the runner pushes its own
runningcommit to.It also never caught the case it was written for. Yuanjun's original stuck job had a run — GitHub just never gave it a runner — so polling for the run's existence would have passed and reported everything fine.
The fix
The dispatch call still surfaces anything GitHub rejects outright, which is the failure mode that actually happens (bad token, missing workflow, bad ref) and it reaches the contributor as an error. What is gone is the polling, the verdict, and the write.
Nothing writes to a job branch after the dispatch. From there the runner owns it.
A run that never starts — dropped dispatch or no runner, indistinguishable from outside — is already covered by the stall detection in the studio: after five minutes on
queuedit offers Restart the build, and writes nothing until the contributor asks. That check is strictly better here, since it measures the thing we care about (did the job start?) rather than a proxy that lags.Companion: HumanStudy-Hub/HumanStudy-Bench#17 makes the runner's push survive a moved branch on its own, so a lost race costs a retry instead of a build.
tsc --noEmit,npm run lint, andnpm run buildpass.🤖 Generated with Claude Code
https://claude.ai/code/session_0185X6NPgr1v2jXVVDnK5DmZ