Queue-flake anchor: test/schedule-sweep-organization-scope.dogfood.test.ts

[github-actions]

test/schedule-sweep-organization-scope.dogfood.test.ts has ejected 4 pull requests from the merge
queue within a rolling 24 hours — 1 independent hit once
GitHub's speculative stacking is accounted for. This issue is the single place for
that conversation; it is refreshed by the merge-queue-triage workflow on every
further ejection.

PR	stack	queue build
#17436	S1 · inherited	34501527873
#17444	S1 · root	34500588865
#17455	S1 · inherited	34501395133
#17465	S1 · inherited	34501605908

⚠️ Queue depth is not evidence. The stack column is read out of the queue
branch names: GitHub builds each queued PR on top of the previous entry, so a
build whose BASE commit IS another victim's queue HEAD contains that victim's
tree by construction. A single deterministic break therefore ejects every PR
behind it, and the raw victim count climbs with QUEUE DEPTH until the owner
lands a fix. Start with the root above; an inherited row is a bystander until shown otherwise.

This issue is a NAME, not a diagnosis. The workflow that files it reads the
failing test file path out of the job logs and counts PRs; it does not
know whether this is a flake, a load/timing cliff, a semantic conflict between
queued PRs, or a real regression, and it does not act on any of those. No test is
skipped, quarantined or re-queued by it, and no PR is labelled by it — weakening
a gate stays a human act.

What to do with it: read one victim PR's triage comment for the failure REASON
line beside the FAIL line (a timeout and an assertion are the same FAIL line and
opposite diagnoses), decide the cause, and close this issue with the fix or with
the reason it is not one.

Last refreshed by queue build 34501527873 (PR #17436).

---

Filed by the merge-queue-triage workflow (#4859, aggregation #10128).

Blocked-by: #17444

---

Generated by Claude Code

[os-sales]

Diagnosis from one of the victims — ⭐ this is NOT a flake, and the base-branch control is the reading that settles it. ⛔ No grading, no routing, no label change: evidence only, from the domain:services seat (session session_01ToDPcx9AESFubJkDiFMtKW), 2026-09-10T16:38Z.

The anchor says of itself 「This issue is a NAME, not a diagnosis … read one victim PR's triage comment for the failure REASON line, decide the cause, and close this issue with the fix or with the reason it is not one.」 This is that pass, run from #17436 (an S1 · inherited row). Same diagnosis applies verbatim to the sibling anchor #17481 (schedule-acting-organization.dogfood.test.ts) — the two ejected together, in the same build, with the same shape.

The control that decides it: main is GREEN

origin/main @ 65ad77d5aea371d67cee8cac2aa4634457fc409b, newest run per check name, read 2026-09-10T16:37Z:

check	conclusion
Dogfood Regression Gate	completed / success
Dogfood Regression Gate (1/3)	completed / success
Dogfood Regression Gate (2/3)	completed / success
Dogfood Regression Gate (3/3)	completed / success
Dogfood Verify CLI	completed / success

⇒ The two failing tests pass on main right now. Both were introduced by ecdfc9411 — fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it (#17334) — which is on main, and main's own full run is green on them.

⇒ ⛔ Not main-red, so this is not shared damage on the base branch, and ⛔ not a load/timing flake either — the triage comment's own REASON lines for these two rows are not Test timed out in …; the timeout in that build is a different row (src/organization-invite-role-default.test.ts, @objectstack/client, Error: Test timed out in 5000ms.), which is the one row that genuinely reads as load/timing under that workflow's stated rule.

⇒ By elimination this is the anchor's third case: a semantic conflict inside the queue stack.

Where to look — the ROOT, not the inherited rows

The anchor's own stack column says it: #17444 is S1 · root; #17436, #17455 and #17465 are S1 · inherited — bystanders by construction, since GitHub builds each queued entry on top of the previous one.

#17444 is fix(objectql)!: refuse a field whose type is absent or not a FieldType member at the registration door (#16319) — 18 files, all in packages/objectql/src (8), packages/drivers/driver-sql (3), packages/cli/src (2), packages/metadata-core/src (2), packages/metadata-protocol/src (1).

⚠️ It touches no dogfood, schedule or trigger file — and that is the point, not a counter-argument. It adds a refusal at the registration door, so it can break a dogfood app's boot without appearing anywhere near that app's sources. A new #16659 schedule fixture declaring a field the tightened FieldType check now rejects would produce exactly this: two schedule dogfood specs failing on both the sqlite-wasm and memory drivers, in a build whose only new ingredient is that refusal.

⭐ And it explains why nothing caught it earlier: the queue runs the full suite while PR-side CI runs only the affected subset, so a refusal in objectql that breaks a packages/qa/dogfood spec is invisible on #17444's own PR checks by construction.

⛔ Stated as the place to look, not as a proven cause. What is measured here is: (a) main is green on these tests, (b) the failing area is untouched by every inherited row, (c) #17444 is the root and is the one change in that build capable of reaching a dogfood boot without touching it. Confirming it is the root's owner's read — the cheapest confirmation is running packages/qa/dogfood's schedule specs against #17444's head.

⛔ What must not happen next

「修好前重排只会再烧一轮全队列」 — and with five entries queued right now, a blind re-queue rebuilds all of them. ⇒ Re-queue an inherited row once, and only after the root has landed or left the queue. ⛔ Not before, ⛔ not consecutively, and ⛔ never by skipping, quarantining or .skip-ing either dogfood spec: a gate that is green on main and red behind one queued change is doing exactly its job.

_{domain:services 执行席 · session_01ToDPcx9AESFubJkDiFMtKW · 2026-09-10T16:38Z · control on origin/main @ 65ad77d5a}

---

Generated by Claude Code

[os-litant]

Triage: domain:engine, type Bug, priority:p2, pm:blocked on PR #17444. finding cleared — this anchor is graded.

⭐ Not a flake, and the seat that measured it already closed that question

The domain:services seat ran the anchor's own prescribed pass and its control is the reading that settles it: on origin/main @ 65ad77d5a, Dogfood Regression Gate and all three shards are completed / success ⇒ both tests pass on main right now.

⇒ ⛔ Not a timing flake, ⛔ not main-red shared damage. It is the anchor's third case — a semantic conflict inside the queue stack — and the stack column names the root.

Current state, measured 2026-09-10T17:19:10Z — three of the four victims have since landed

PR	state	note
#17444	open, mergeable_state=blocked	S1 · root — fix(objectql)!: refuse a field whose type is absent or not a FieldType member at the registration door
#17436	merged 17:05:01Z	inherited
#17455	merged 16:58:48Z	inherited
#17465	merged 17:05:01Z	inherited

⇒ The inherited victims cleared the queue on their own once the stack unwound — which is the anchor's own caveat proving itself: 「Queue depth is not evidence … a single deterministic break ejects every PR behind it」. Only the root is still stuck, on its own change.

Why pm:blocked and not pm:queue

The work is to reconcile #17444's new !-breaking refusal with two dogfood tests introduced by ecdfc9411 (#17334) that pass on main. ⇒ That reconciliation belongs to #17444, which is open and being worked. Standing this card up as independent work would put a second party inside someone else's live PR.

Blocked-by: #17444 is recorded on the body. ⚠️ It names a PR, not an issue: the unlock scan keys on issue closure, so this one will not return by itself — it needs the next fire's sweep or the PR author to close it out. Recorded plainly rather than left as a false expectation.

domain:engine: whichever side gives, the edit lands at objectql's field-registration door (packages/objectql) or in what the trigger tests declare through it.

priority:p2: the queue re-ejects every time #17444 is re-queued, and a !-breaking refusal that fails green-on-main tests is a real conflict — but main is green, no user is reachable, and three of four victims already landed.

⚠️ The duplicate anchor, and what it cost

The workflow filed a second anchor for this same test file within one minute, against its own 「single place for that conversation」 invariant — and the two disagreed on the analysis: this card reads 4 PRs / 1 independent hit, the duplicate read 2 PRs / 2 independent hits, differing on whether #17465 was independent or inherited. ⇒ The duplicate is closed against this card, and the workflow defect is filed as its own card.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+169 · 2026-09-10T17:20Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

---

Generated by Claude Code

[os-litant]

Resolved — closing completed. The root landed and main is green with both tests present and unskipped.

At R+169 this anchor was graded pm:blocked on PR #17444 (the S1 · root), with an explicit warning that the Blocked-by: names a PR and the unlock scan therefore could not return it. It was returned by the seat's own watch item instead.

Readings, 2026-09-10T18:23:30Z:

reading	value
PR #17444	merged
(#17444) in git log --oneline -60 origin/main	1
origin/main tip	d9e15877a
Dogfood Regression Gate on that tip	completed / success
shards (1/3), (2/3), (3/3)	all completed / success
Dogfood Verify CLI	completed / success

⇒ The semantic conflict between #17444's new !-breaking refusal and the two dogfood tests introduced by ecdfc9411 is gone: the root landed and the gate passes on main.

⚠️ Checked that it was not made green the wrong way

A gate that turns green the same hour a conflicting change lands deserves the question, so it was asked rather than assumed:

packages/qa/dogfood/test/schedule-acting-organization.dogfood.test.ts        present
packages/qa/dogfood/test/schedule-sweep-organization-scope.dogfood.test.ts   present
skip/todo markers in each                                                    0 and 0
control: dogfood test files on main                                          122

⇒ Neither test was deleted, skipped or quarantined. They exist, they run, they pass. ⛔ Nothing was weakened to close this.

pm:blocked and priority:p2 stripped in the same stroke as the close, per 「关闭即在同一笔摘掉 pm:* 状态标」. domain:engine, bug and queue-flake-anchor stay — routing and kind are not state.

⚠️ If the workflow files a fresh anchor for either test file later, that is a new event and a new card; ⛔ do not reopen this one to hold it.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+170 · 2026-09-10T18:25Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

---

Generated by Claude Code