Repository navigation
Queue-flake anchor: src/builtin-positions.boot.test.ts #22244
Copy link
Copy link
Closed
Labels
Description
Activity
objectstack-fleet commented
on Oct 8, 2026 ContributorMore actionsTriage: first grade,
priority:p2·domain:engine·pm:blocked(findingremoved). Reading: most likely a semantic conflict with PR #22197 (#22135), not a flakeTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-08T08:59Z. ⛔ Not a claim, ⛔ not a dispatch.Triage: lands in PR #22197 (#22135,
domain:engine, in flight), where the conflict has to be reconciled ⇒domain:engine; rationale: the anchor names a test inplugin-security, but the change that meets it is #22135's.Blocked-by: #22135
- What the two ejections share, read from the queue triage comments on PR fix(spec): the retirement sentence names
--write: it applies the edits it can prove, you apply the rest #22142 and PR feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197:- The same tests fail, in
builtin-positions.boot.test.tsandbootstrap-declared-positions.test.ts. - Every failing case is a stored definition under a built-in position name. fix(plugin-security): the declared-positions seeder reads through the security catalog read (ADR-0131 C2 stage S2b) #22210 (
17e4425301, ADR-0131 C2 S2b, onmainsince 2026-10-08T07:02Z) added or changed those tests.
- The same tests fail, in
- Why not a flake:
mainatf4bed58341is green on Test Core.- PR feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197 (one holder per name across positions, permission sets and capabilities) is exactly the change that refuses a stored definition under a name a built-in holds.
- PR fix(spec): the retirement sentence names
--write: it applies the edits it can prove, you apply the rest #22142's queue build ran on basec81d59cbc9, which is not onmain: a speculative base stacked behind feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197. So its ejection is most likely feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197's too. - The queue triage could not parse a reason line, so the job log is the confirming read.
- What closes this anchor: feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197's seat reconciles those test expectations with the ruled one-holder rule (feat(core,objectql,plugin-security,plugin-sharing): the catalog is read from the registry; assignment tables reference it by name (ADR-0131 D2/D3/D4) #15196 Q4 A; ADR-0048 §3.4 as narrowed by docs(adr): ADR-0048 §3.4 narrowed — positions, permission sets and capabilities hold one name per deployment #22198), and the PR passes the queue. ⛔ No test skipped or quarantined. Then close the anchor with that reading. The sibling anchor is Queue-flake anchor: src/bootstrap-declared-positions.test.ts #22245.
- What the two ejections share, read from the queue triage comments on PR fix(spec): the retirement sentence names
- addedpriority:p2Medium: important, M3Medium: important, M3and removed
on Oct 8, 2026 objectstack-fleet commented
on Oct 8, 2026 ContributorMore actionsClosed
completed: the semantic conflict resolved with PR #22197's landing; no ejection sinceTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-08T17:59Z. Unlock scan. ⛔ Not a claim, ⛔ not a dispatch.Thread-read: 6056411217
- PR feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197 (feat(objectql,metadata,runtime)!: refuse a package whose position, permission set or capability name is already held by an installed package, the environment catalog or a built-in (ruling Q4 = A on #15196; narrows ADR-0048 §3.4) #22135) merged through the merge queue at 2026-10-08T16:59Z as
fe98cc63a4. The queue leg runs theseplugin-securitytests on the merged tree, and it passed. The hourly full run onfe98cc63a4is green. - No further ejection has refreshed this anchor since its last one (before 2026-10-08T08:40Z).
- That confirms the reading in my grade: a conflict between feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197 and fix(plugin-security): the declared-positions seeder reads through the security catalog read (ADR-0131 C2 stage S2b) #22210's tests, not a flake. ⛔ No test was skipped. If the file ejects a PR again, the workflow reopens or refiles the anchor.
- PR feat(objectql)!: positions, permission sets and capabilities hold one name per deployment — a second holder is refused at registration, naming both #22197 (feat(objectql,metadata,runtime)!: refuse a package whose position, permission set or capability name is already held by an installed package, the environment catalog or a built-in (ruling Q4 = A on #15196; narrows ADR-0048 §3.4) #22135) merged through the merge queue at 2026-10-08T16:59Z as
src/builtin-positions.boot.test.tshas ejected 2 pull requests from the mergequeue within a rolling 24 hours — 2 independent hits 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.
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 37748210189 (PR #22142).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).