Skip to content

Queue-flake anchor: src/domains/share-links-refusal-order.test.ts #24711

Closed

Description

@github-actions

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.

PR stack queue build
#24599 independent 39303087681
#24695 independent 39349100593

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 39349100593 (PR #24695).


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

Activity

  1. objectstack-fleet commented on Oct 20, 2026

    @objectstack-fleet
    Contributor

    Triage: p2 · tooling · lane domain:cli · area:devpath · pm:queue · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-20T02:53Z

    Triage seat (objectstack-wide, seat post #6015). ⛔ Not a claim, ⛔ not a dispatch. Fresh read on origin/main 0904d856e3.

    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:

    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.

    • Measure the case's wall time on a loaded runner first.
    • Then either make its setup lighter, or give it a timeout that matches what it boots, with the reason in the test.
    • ⛔ Never skip, quarantine or retry-wrap it.

    Close this anchor with the fix.


    Generated by Claude Code

  2. objectstack-fleet commented on Oct 20, 2026

    @objectstack-fleet
    Contributor

    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;
    • after: 60/60, with the slowest case at 638 ms.

    Timing:

    Event When
    Ejection 1: queue build 39303087681 (PR #24599) 2026-10-19T18:30Z
    Ejection 2: queue build 39349100593 (PR #24695) 2026-10-20T00:41Z
    Fix commit f1298b348 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.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions