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 }}
Repository navigation
quest: plan judging checks by their latest run on the head - #422
quest status, quest wait, and the quest land gate count every check run on a head. When a newer run of a check replaces an older one, the older run still fails them, even though GitHub merges the head. Example: moq-dev/moq#7325, where a cancelled Release gate run sat beside a passing one on the same head. The quest records what was read on that head:
the rollup lists both runs
the rollup's own state is FAILURE
REST filter=latest dedupes only within a check suite
gh pr checks keeps the newest run per name, workflow, and event
It also names every place that judges checks: status.ts, wait.ts, the gate's checks in land.ts, and the Worker's readTarget.
Decisions
Milestone: m0 (maintainer, 2026-11-02, replacing the earlier m1 pick from the same day). Since moq-dev/quest#229, the quest land gate fails a check name if any run with that name failed. So it can wrongly refuse release-plz PRs that GitHub would merge, which makes this land work. The file moved from quest/m1/ to quest/m0/latest-check-runs.md. Both milestone READMEs' Required lists, the cross-link in quest/m0/status-landing.md, and the quest's Plan are updated to match.
Choices made while planning
Split from Current landing status. That m0 quest owned a one-line version of this ("count only the newest run of each check name"). It now keeps only its landing-stopped half. The two halves can be completed separately, and both stay in m0.
Scope covers the gate and the Worker, not only quest status.land.ts deliberately fails a name if any of its reports fails (from moq-dev/quest#229). That makes the gate reject heads that GitHub merges, so the plan reverses that rule.
Rule: key check runs by app and name, which is the identity a required check has in GitHub. Key commit statuses by context. The latest run is the one created last (highest databaseId). The checks state comes from those latest runs, not from the rollup's state. gh pr checks' key was rejected because its list can disagree with mergeability.
Size:[S]. It's one shared helper in src/github/, used in four places, plus regression fixtures recorded from #7325.
Validation
quest check and quest check --base origin/main: 90 documents ok
nix develop -c just check: passed
just test not run, since this PR only changes the quest tree
CodeRabbit findings (fixed in c4d08d6)
status-landing.md: its Goal now says re-queueing clears the stale reason, so quest status prints landing-stopped -. That keeps statusLines' output contract instead of dropping the line.
latest-check-runs.md Goal: it now claims to match the merge state GitHub reported on #7325, not a documented GitHub rule.
latest-check-runs.md Plan: it now lists the fields each producer must fetch (CheckRun.databaseId, the check suite's app databaseId, status createdAt), notes which of status, wait, land, and the Worker lack them, and gives statuses a tie-breaker.
Review
Round 2 (session 01a19f5d): quest review --base origin/main, reviewer Codex gpt-6.1-sol at medium effort, head c4d08d6d1466b07f8456bf3ae061f567d0e55cd2 against base 91058d2. It reported no findings. Round 1, on d53b720, also had none.
quest status, quest wait, and the quest land gate count every check run on
a head, so a run that a newer run of the same check replaced still fails
them although GitHub merges the head (moq-dev/moq#7325). Plan the fix in
m1 and split it from the m0 landing-status quest.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The quest land gate fails a check name if any run with that name failed
(since #229), so it can wrongly refuse release-plz PRs that
GitHub would merge. Maintainer decision 2026-11-02: land work, m0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The m0 planning documents now focus on stale landing-stopped output after a PR is queued again. The m1 README links to a new specification for evaluating each check’s latest run across quest status, quest wait, the quest land gate, and Worker paths. The specification records check identity, latest-run selection, state precedence, and planned tests.
Merge Risk: Low · up to e6fc8
The change is documentation-only and mergeable with owner awareness. Clarifying the latest-run plan before implementation would reduce the risk of inconsistent check handling.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the main change: the PR plans judging checks by their latest run on the PR head. The raw summary confirms the added m1 plan document (latest-check-runs.md) covers this change across st…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Description check
The description is clearly related to the changeset. It explains that the PR plans judging checks by their latest run in m0, links the affected quest files, and names the code paths (status.ts, wait.t…
Full details: Title check
Explanation
The title names the main change: the PR plans judging checks by their latest run on the PR head. The raw summary confirms the added m1 plan document (latest-check-runs.md) covers this change across status, wait, the land gate, and the Worker. The title is specific and concise.
Full details: Description check
Explanation
The description is clearly related to the changeset. It explains that the PR plans judging checks by their latest run in m0, links the affected quest files, and names the code paths (status.ts, wait.ts, land.ts, readTarget) that the plan covers. It also gives the rule, the decisions, and the validation done, so it is specific and not off-topic.
Finishing Touches
Simplify code
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Run CodeRabbit Verify to test the changes in this pull request.
Recent review info
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: ec03c0e2-2c50-4688-8d8e-3120a1ec71bc
Commits
Reviewing files that changed from the base of the PR and between 91058d2 and e6fc861.
Files selected for processing: 4
quest/m0/README.md
quest/m0/status-landing.md
quest/m1/README.md
quest/m1/latest-check-runs.md
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
Main split the check-run half of this quest into quest/m0/latest-check-runs.md
(#422). Keep that quest, delete status-landing.md, which this PR
completes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Complete quest/m0/latest-check-runs.md, which main split from this PR's
quest in #422, and delete it.
- Move the latest-run filter to src/github/checks.ts, shared by the CLI
and the Worker, and key commit statuses by context and newest createdAt.
- quest status derives its checks state from the latest runs instead of
the rollup state, which counts superseded runs.
- The Worker's job context lists only the latest runs, with a state
derived from them.
- Regression tests shaped after moq-dev/moq#7325 for status, wait, the
land gate, and the Worker.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Summary
Plans Checks are judged by their latest run in m0, ranked just above Current landing status among the land quests.
quest status,quest wait, and thequest landgate count every check run on a head. When a newer run of a check replaces an older one, the older run still fails them, even though GitHub merges the head. Example: moq-dev/moq#7325, where a cancelledRelease gaterun sat beside a passing one on the same head. The quest records what was read on that head:stateisFAILUREfilter=latestdedupes only within a check suitegh pr checkskeeps the newest run per name, workflow, and eventIt also names every place that judges checks:
status.ts,wait.ts, the gate'schecksinland.ts, and the Worker'sreadTarget.Decisions
quest landgate fails a check name if any run with that name failed. So it can wrongly refuse release-plz PRs that GitHub would merge, which makes this land work. The file moved fromquest/m1/toquest/m0/latest-check-runs.md. Both milestone READMEs'Requiredlists, the cross-link inquest/m0/status-landing.md, and the quest's Plan are updated to match.Choices made while planning
landing-stoppedhalf. The two halves can be completed separately, and both stay in m0.quest status.land.tsdeliberately fails a name if any of its reports fails (from moq-dev/quest#229). That makes the gate reject heads that GitHub merges, so the plan reverses that rule.databaseId). Thechecksstate comes from those latest runs, not from the rollup'sstate.gh pr checks' key was rejected because its list can disagree with mergeability.[S]. It's one shared helper insrc/github/, used in four places, plus regression fixtures recorded from #7325.Validation
quest checkandquest check --base origin/main: 90 documents oknix develop -c just check: passedjust testnot run, since this PR only changes the quest treeCodeRabbit findings (fixed in
c4d08d6)status-landing.md: its Goal now says re-queueing clears the stale reason, soquest statusprintslanding-stopped -. That keepsstatusLines' output contract instead of dropping the line.latest-check-runs.mdGoal: it now claims to match the merge state GitHub reported on #7325, not a documented GitHub rule.latest-check-runs.mdPlan: it now lists the fields each producer must fetch (CheckRun.databaseId, the check suite's appdatabaseId, statuscreatedAt), notes which of status, wait, land, and the Worker lack them, and gives statuses a tie-breaker.Review
Round 2 (session
01a19f5d):quest review --base origin/main, reviewer Codexgpt-6.1-solat medium effort, headc4d08d6d1466b07f8456bf3ae061f567d0e55cd2against base91058d2. It reported no findings. Round 1, ond53b720, also had none.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code