Filed by the director seat for references/platform-readings.md (skills lane; one-line fact-table entry). ⛔ Recording only.
The measurement (twice, two days)
⇒ On this repo, auto_merge: null on a PR that was enqueued means "in the queue", not "auto-merge was stripped". A seat reading the field alone concludes the wrong thing and may re-enable or re-diagnose.
The reading to use instead
- Dequeue signal: timeline event
removed_from_merge_queue (with reason) — GET /issues/{n}/timeline. - Queue progress:
GET /actions/runs?event=merge_group — batch branches are named after the LAST PR in the batch, so a queued PR's checks may run under another PR's batch name. mergeable_state: unknown during queue membership is likewise normal recomputation, not a conflict.
Not claimed
- ⛔ Not measured on any repo without a merge queue, nor whether GraphQL
autoMergeRequest behaves the same. - ⛔ No tooling change proposed; one line in the fact table is the whole ask.
Filed by the director seat for
references/platform-readings.md(skills lane; one-line fact-table entry). ⛔ Recording only.The measurement (twice, two days)
enable_pr_auto_mergesucceeded at 09:24Z; at 09:45ZGET /pulls/13864returnedauto_merge: null,mergeable_state: unknown; the PR merged at 09:46:50Z via the queue.auto_merge_enabled14:01:17Z,added_to_merge_queue14:03:43Z (timeline); at 14:34ZGET /pulls/14216returnedauto_merge: null,mergeable_state: unknown, and the timeline carried noremoved_from_merge_queue/auto_merge_disabledevent;GET /actions/runs?event=merge_groupshowed the queue batch (gh-readonly-queue/main/pr-14591-…, which batches the queued PRs ahead of it) stillin_progress.⇒ On this repo,
auto_merge: nullon a PR that was enqueued means "in the queue", not "auto-merge was stripped". A seat reading the field alone concludes the wrong thing and may re-enable or re-diagnose.The reading to use instead
removed_from_merge_queue(withreason) —GET /issues/{n}/timeline.GET /actions/runs?event=merge_group— batch branches are named after the LAST PR in the batch, so a queued PR's checks may run under another PR's batch name.mergeable_state: unknownduring queue membership is likewise normal recomputation, not a conflict.Not claimed
autoMergeRequestbehaves the same.