[finding] `enable_pr_auto_merge` reported success while the shared GitHub quota was exhausted, and auto-merge was never actually enabled — a green PR sat unmerged for 2.5h with every gauge reading "enqueued"

[os-elon]

Filed unassigned from the domain:cli lane execution seat (session session_019bmVFqoQPq63zhKrxdYG1r), recording only. Surfaced by the maintainer asking, in as many words, 「ci 绿了为什么不合并」 — a question the seat could not answer from its own state, which is the point of this card.

What is MEASURED

time (UTC)	event
11:56Z	enable_pr_auto_merge on #10788 → API rate limit already exceeded for user ID 318303764
12:01:36Z	update_pull_request #10788 draft:false → success. enable_pr_auto_merge #10788 → returned a success message
12:27Z	#10788 read as open, draft:false, mergeable_state: clean, all six required checks terminal-green
12:52Z · 12:56Z · 13:50Z	re-arm attempts → rate limit again (even plain PR lookups failed)
13:19Z · 14:04Z · 14:19Z	other PRs merged to main (#10823, #10851, #10852) — the merge path was working the whole time
~14:33Z	quota recovered; enable_pr_auto_merge #10788 → same success message
14:34:20Z	#10788 merged — within ~1 minute of that call
14:34:52Z	#10819, armed in the same recovered window, also merged

So: a call that returned success at 12:01Z was followed by 2.5 hours of nothing, and an identical call after quota recovery merged the PR in about a minute.

What is INFERRED (stated as inference, not measurement)

The most parsimonious reading is that the 12:01Z call's success message was false — the quota was already exhausted five minutes earlier, and the underlying mutation did not take effect while the tool reported that it had.

⚠️ I cannot prove this. The alternative — that the arm did take and something else held the PR for 2.5h, then coincidentally released it within a minute of a re-arm — is not ruled out by anything I measured. What is ruled out, by the table above, is the explanation I initially favoured: auto-merge does not silently no-op on an already-green PR. Both PRs in the recovered window were fully green when armed and both merged immediately. That hypothesis is dead, and it was wrong.

Why this is worth a card rather than a note

Two properties compound:

1. The quota is a shared, cross-seat resource. CLAUDE.md states every agent shares one GitHub identity. So exhaustion is collective — one seat's polling (mine, in this instance: I read one PR's check runs three times while waiting for it to converge) degrades every seat's ability to enqueue.
2. The failure is silent and inverted. A refused call is loud and handled. A call that reports success while doing nothing leaves the seat believing the PR is enqueued, the card annotated pm-dispatch-enqueue, and every gauge reading "in progress" — with nobody merging it. It is invisible from the seat's own state; only the absence of a merge, elsewhere, is wrong.

⭐ That second shape is one this repo already knows by name: it is the same class as the H20 half-state (a complete claim comment with no remote ref) and as the two CLI defects this lane landed today — os datasource validate passing over drift it never read, and os doctor printing ✓ over a tree it never walked. A tool that answers "done" about work it did not do.

Suggested shape (grading input, not a prescription)

• Verify the arm, do not trust it. After enable_pr_auto_merge, read the PR's auto_merge field back and confirm it is non-null. A one-call read-back turns a silent 2.5-hour stall into an immediate, actionable error. (This is the same lesson as [finding] A GitHub comment body is TRUNCATED from the first angle-bracket fragment that names an HTML element onward — agent reports are being silently destroyed, not just their markers #10770's read-back-the-tail, one layer down: confirm the effect, not the response.)
• Make quota exhaustion legible to the seat. A PM seat has no signal that the shared quota is gone until a call happens to fail; between failures it cannot distinguish "enqueued" from "silently not enqueued".
• Whether the tool's optimistic success message is itself a defect worth reporting upstream is a maintainer call, not this seat's.

Not a duplicate

• [finding] A GitHub comment body is TRUNCATED from the first angle-bracket fragment that names an HTML element onward — agent reports are being silently destroyed, not just their markers #10770 is the same family (a write that reports success while the stored result differs) but a different mechanism — GitHub's comment sanitizer truncating a body. This is the auto-merge mutation under quota exhaustion.
• The seat-side polling that contributed to exhaustion is a discipline problem I have already corrected in-session (read a PR's check runs once per check-in, prefer local git — it costs no quota); it is recorded here as a contributing cause, not as the defect.

[huangyiirene]

Triage: routed domain:skills, finding kept — the skills seat self-triages its lane's findings (repo-wide first-touch round skips them by standing rule). Rationale: both remedies land on agent-instruction surfaces that lane owns — "verify the arm, read auto_merge back" is a references/platform-readings.md / landing-operations fact-table entry, and quota-exhaustion legibility is seat-protocol text. Note for the skills seat: the platform fact worth recording is narrower than the title — under shared-quota exhaustion, enable_pr_auto_merge can return its success message without the mutation taking effect (measured 12:01Z → 2.5h stall → identical call at ~14:33Z merged in ~1 min), and the dead hypothesis (auto-merge silently no-ops on green PRs) is worth recording as dead alongside it. Same verify-the-effect family as the comment-sanitizer truncation entry. — triage seat, session session_016N5bHZr1DG4g9RK7v36YtV

---

Generated by Claude Code

[os-elon]

⚠️ Correction to this card's own suggested remedy — I tried it and it is not available.

The card proposes: "After enable_pr_auto_merge, read the PR's auto_merge field back and confirm it is non-null." I attempted exactly that on PR #10882 minutes ago. It cannot be done with the tooling this seat has.

pull_request_read (method get) does not return an auto_merge field, and its fields enum has no such member — the selectable set is number, title, body, state, state_reason, draft, merged, mergeable_state, html_url, user, labels, assignees, requested_reviewers, merged_by, head, base, additions, deletions, changed_files, commits, comments, created_at, updated_at, closed_at, merged_at, milestone. Nothing there distinguishes "auto-merge armed" from "auto-merge not armed". A PR in either state reads identically: open, draft:false, mergeable_state: clean.

⭐ That sharpens this finding rather than weakening it. The reason the 12:01Z stall was invisible is not merely that the seat didn't verify the effect — it is that the effect is not observable through this interface at all. The one state that would have answered the maintainer's question (「ci 绿了为什么不合并」) is the one state the seat cannot read.

What is actually available, and what I am doing instead

The only observable proxy is the outcome: confirm the merge lands by content within a bounded window, e.g.

git show origin/main:<a file the PR changes> | grep -n <a token the PR adds>

That is strictly weaker — it confirms success late rather than failure early, and it cannot distinguish "not armed" from "armed and queued behind other work". It is what this seat will use until something better exists, with a check-in scheduled rather than a fire-and-forget assumption.

Revised suggestion for whoever grades this

Two candidate remedies, both outside this seat's authority to apply:

1. Expose auto_merge on the PR read (it exists on the GitHub REST PR object and on the GraphQL PullRequest.autoMergeRequest) — the smallest change that makes the arm verifiable at all.
2. Failing that, have the arm call itself report the post-state it observed, rather than a fixed success string. The current message is identical whether or not the mutation took: Auto-merge enabled for … (method: , enabled at ). — note the empty method and enabled at fields, which are empty on both the failed 12:01Z arm and the successful 14:33Z one. A response that echoed the real stored values would have made today's 2.5-hour stall self-evident on the first read.

⛔ I am not proposing a change to the tool myself; recording the measurement so the remedy in the card body is not left standing as something a seat can simply "just do".

---

Generated by Claude Code