You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
src/domains/share-links-refusal-order.test.ts has ejected 2 pull requests from the merge
queue 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.
Triage seat (objectstack-wide, seat post #6015). ⛔ Not a claim, ⛔ not a dispatch. Fresh read on origin/main0904d856e3.
Lane. The file is packages/runtime/src/domains/share-links-refusal-order.test.ts, which is domain:cli (SKILL.md:166).
Diagnosis from the victims' REASON lines, read as this anchor asks. Both ejections are Error: Test timed out in 5000ms on the "[#23372] email audience" case:
Closed with the fix: PR #24704 → f1298b348 (#24633)
domain:cli seat 2 · os-justin · session session_01LmjU2x1faLZ39DVTFyVca6 · 2026-10-20T04:28Z. This card is closed the way it asks ("close this issue with the fix"), in the same stroke that removes pm:queue.
Cause, from the victims' REASON lines (triage 6282227449): both ejections are Error: Test timed out in 5000ms on the "[#23372] email audience" loop case, one on the plugin-route twin and one on the dispatcher twin. That is a timeout, not an assertion. #24633 measured why: production scrypt verifications inside the loop cases. That file made 74 derivations per run, with 8, 4 and 10 of them inside the three loop cases.
The fix: PR #24704 (#24633) memoises the ShareLinkService instance's production verifier per (password, hash) pair, so a run makes 10 derivations and the loop cases make none fresh. Every request and every matrix cell is still asserted, and no case is skipped, re-timed or retry-wrapped. Measured by its dev under contention (the file pinned to one core beside five busy loops):
before: 3 × Test timed out in 5000ms, including the email-audience case on both twins;
2026-10-20T02:55Z; merged to main 2026-10-20T03:26Z
Both ejections predate the fix, and the merge-queue-triage workflow has not refreshed this anchor since. If a queue build after f1298b348 names this file again, the workflow refreshes this anchor and it reopens as a new diagnosis.
Activity
objectstack-fleet commentedon Oct 20, 2026
Triage: p2 ·
tooling· lanedomain:cli·area:devpath·pm:queue· triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-20T02:53ZTriage seat (objectstack-wide, seat post #6015). ⛔ Not a claim, ⛔ not a dispatch. Fresh read on
origin/main0904d856e3.Lane. The file is
packages/runtime/src/domains/share-links-refusal-order.test.ts, which isdomain:cli(SKILL.md:166).Diagnosis from the victims' REASON lines, read as this anchor asks. Both ejections are
Error: Test timed out in 5000mson the "[#23372] email audience" case:Neither is an
AssertionError, so this is load or timing on one case, not a behaviour change.Why p2. It ejected 2 independent PRs in 24 h from the shared merge queue (
triage-duties.md:37, measured re-runs).Shape.
Close this anchor with the fix.
Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
Closed with the fix: PR #24704 →
f1298b348(#24633)domain:cliseat 2 ·os-justin· sessionsession_01LmjU2x1faLZ39DVTFyVca6· 2026-10-20T04:28Z. This card is closed the way it asks ("close this issue with the fix"), in the same stroke that removespm:queue.Cause, from the victims' REASON lines (triage
6282227449): both ejections areError: Test timed out in 5000mson the "[#23372] email audience" loop case, one on the plugin-route twin and one on the dispatcher twin. That is a timeout, not an assertion. #24633 measured why: production scrypt verifications inside the loop cases. That file made 74 derivations per run, with 8, 4 and 10 of them inside the three loop cases.The fix: PR #24704 (#24633) memoises the
ShareLinkServiceinstance's production verifier per(password, hash)pair, so a run makes 10 derivations and the loop cases make none fresh. Every request and every matrix cell is still asserted, and no case is skipped, re-timed or retry-wrapped. Measured by its dev under contention (the file pinned to one core beside five busy loops):Test timed out in 5000ms, including the email-audience case on both twins;Timing:
39303087681(PR #24599)39349100593(PR #24695)f1298b348main2026-10-20T03:26ZBoth ejections predate the fix, and the merge-queue-triage workflow has not refreshed this anchor since. If a queue build after
f1298b348names this file again, the workflow refreshes this anchor and it reopens as a new diagnosis.Generated by Claude Code