[kixelated]

Completes quest/m0/status-landing.md and quest/m0/latest-check-runs.md, deleting both along with their links in the m0 README.

Summary

• landing-stopped clears once the PR is queued again. summarize in src/cli/status.ts still picks the latest merge-queue removal, auto-merge disable, or quest land ejection from the timeline. It now drops that event when auto-merge's enabledAt or the merge-queue entry's enqueuedAt is at or after it. The comparison is >= because quest merge --land (enqueue in src/cli/land.ts) disables auto-merge and enables it again, usually within the same second.
• Each check is judged by its latest run, as GitHub's mergeability does. The new src/github/checks.ts is shared by the CLI and the Worker:
  • latestContexts keeps one report per check, in rollup order. A check run is keyed by app (checkSuite.app.databaseId) and name, and the highest databaseId wins. A commit status is keyed by context, and the newest createdAt wins; on a tie, the one listed later. A check run and a status with the same name stay separate.
  • contextOutcome and checksState classify those reports.
• Every reader filters through it:
  • quest status counts and lists only the latest runs. Its checks state is now derived from them (failure, else pending, else success) instead of the rollup's state, which counts superseded runs.
  • quest wait ignores superseded runs, so they never wake it as checks:failed.
  • The quest land gate checks only the latest runs. This reverses the "a rerun counts only once every report passes" rule from moq-dev/quest#229. A name from more than one app, or as both a run and a status, still needs every report to pass.
  • The Worker's job context (readTarget in cloudflare/src/github/service.ts) lists only the latest runs, with a state derived the same way.
• Each query asks for the fields the helper keys by: databaseId and checkSuite { app { databaseId } } on check runs, and createdAt on statuses.
• README.md, cloudflare/README.md, and the quest status --help text describe both behaviours.

Decisions

• Should fix(status): judge landing and checks as they are now #413 complete both quests (status-landing and latest-check-runs)? Settled in /quest-complete on 2026-11-03.
  • ✅ Keep both (Recommended)
  • Narrow to landing

Choices made without asking

• Followed the newer quest plan, widening this PR. moq-dev/quest#422 merged after this PR's last review. It split the check-run half of this PR's quest into latest-check-runs.md, with a fuller plan. This PR had already implemented most of that plan, so the merge of origin/main brought it up to the plan rather than leave the two overlapping: the shared helper in src/github/, deduplicating statuses, deriving the checks state, and the Worker. That also covers this PR's earlier readTarget follow-up. It is recorded in this comment.
• "Latest" means the highest check-run databaseId. GitHub numbers check runs as it creates them. This is simpler than startedAt, which is null while a run is queued.
• Runs are grouped by app and name, not by workflow. That is how GitHub's required checks identify a check. Two Actions workflows with a job of the same name collapse into one check, as they do for branch protection. gh pr checks' key (name, workflow, event) was rejected, since its list can disagree with mergeability.
• The fake GitHub in cloudflare/dev/github.ts now numbers check runs in the order they are listed (oldest first).

Tests

• test/checks.test.ts, new:
  • The #7325 shape: a cancelled Scope and a failed Release gate, superseded by passing runs, judge as SUCCESS.
  • A newer queued run makes a check pending, and a newer failure fails it, whatever the listing order.
  • The same name from two apps, or as a run and a status, counts separately.
  • Statuses keep the newest createdAt, the later one on a tie.
  • Outcomes for each GitHub result.
• test/status.test.ts:
  • The landing exit clears after re-entry through auto-merge (same second), an ejection, or the merge queue, and stays when the entry is older than the exit.
  • Only the latest run per name and app counts.
  • The #7325 shape prints checks success passed=2 although the rollup says FAILURE.
  • The query asks for the fields it keys by.
• test/wait.test.ts: a cancelled required run superseded by a rerun, and the #7325 shape, never wake the wait as checks:failed; each reports checks:passed once the newer run passes.
• test/land.test.ts: a passing rerun and the #7325 shape keep the PR queued; a newer cancelled run, or a failure from another app, ejects it.
• cloudflare/test/publish.test.ts: the job context lists only the latest runs, keeps another app's failure, and derives its state from them.
• just check, just test (1005 CLI and 506 Worker tests), and quest check --base origin/main pass locally on 1e29db7d, which merges origin/main at d7ef15ec.

Review

mechanical fix by quest land watch: merged main at 66ab4fb2e492b162cd64c90f5f56b46fa3ca62c7 with the quest merge driver (head c050772)

• Reviewer: Codex (gpt-6.1-sol, medium effort), via quest review --base origin/main (session 01a19f5f, started with --new after the design change).
• Round 3 on 1e29db7d66417febf4e7345b0d939ccd8a032e94: no findings. That head merges origin/main (d7ef15ec). The merge hand-resolved import conflicts in src/cli/wait.ts and cloudflare/src/github/service.ts. Its added and removed lines match 9f9e217e's against the new base, but the merge needed a hand resolution, so the new head got its own review round.
• Round 1 on 9f9e217e had one finding: CheckRun.databaseId is a 32-bit GraphQL Int, so it could be null for modern IDs, and the comparison would then keep the first run. Refuted.
  • Live GraphQL on moq-dev/moq#7325's head returns non-null IDs far past 2^31 for every check run, such as 125683011259.
  • Schema introspection shows databaseId is not deprecated, and CheckRun has no fullDatabaseId.
  • JavaScript numbers hold these IDs exactly.
• Round 2 on 9f9e217e, with that response: no findings.
• Earlier rounds, superseded: round 1 on 1ea6dcf5 (missing query fields, fixed in 3741b977) and round 2 on 3741b977, with no findings.

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

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: 3978506e-2ec3-449c-943d-76ecd7fa0702

• 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.

Share

• X
• Mastodon
• Reddit
• LinkedIn

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

[kixelated]

Design change: this PR now also completes quest/m0/latest-check-runs.md. moq-dev/quest#422 merged after this PR's last review and split its check-run half into that quest, with a fuller plan. This PR already implemented most of that plan, so it follows the newer plan here instead of leaving a partial overlap:

• The latest-run filter moved to src/github/checks.ts, which the CLI and the Worker share.
• Commit statuses are also keyed by context and newest createdAt.
• quest status derives its checks state from the latest runs instead of the rollup's state.
• The Worker's job context (readTarget) lists only the latest runs.
• New tests shaped after chore: release moq#7325.

The review session restarted with quest review --new.

(Written by Claude Opus 5.5)

[moq-bot]

quest land watch: the merge queue removed this pull request at 1e29db7 because it conflicts with main (merge_conflict).

The land fixer works on it in the background, and the watcher re-enqueues it at the back of the queue once it is fixed or judged flaky, or hands it back here with what it needs.

(written by quest land watch)

[moq-bot]

quest land watch: armed auto-merge on this pull request at c050772, so it joins the back of the merge queue once its required checks pass, with main at 66ab4fb merged in by the quest merge driver.

(written by quest land watch)