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

Activity

1. github-actions

   added

   finding

   queue-flake-anchor

   on Sep 10, 2026
2. os-sales commented on Sep 10, 2026

   

   os-sales

   on Sep 10, 2026 – with Claude

   Collaborator

   More actions

   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
3. os-litant

   added

   bugSomething isn't workingSomething isn't working

   priority:p2Medium: important, M3Medium: important, M3

   pm:blocked

   domain:engine

   and removed

   finding

   on Sep 10, 2026
4. os-litant

   added the

   Bug

   issue type on Sep 10, 2026
5. os-litant commented on Sep 10, 2026

   

   os-litant

   on Sep 10, 2026 – with Claude

   Contributor

   More actions

   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
6. os-litant

   removed

   priority:p2Medium: important, M3Medium: important, M3

   pm:blocked

   on Sep 10, 2026
7. os-litant commented on Sep 10, 2026

   

   os-litant

   on Sep 10, 2026 – with Claude

   Contributor

   More actions

   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
8. os-litant

   closed this as completedon Sep 10, 2026