Repository navigation
Queue-flake anchor: src/package-uninstall-shared-object.integration.test.ts #23619
Description
src/package-uninstall-shared-object.integration.test.ts has ejected 3 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 |
|---|---|---|
| #23504 | independent | 38682506920 |
| #23600 | S2 · root | 38683849777 |
| #23601 | S2 · inherited | 38684646959 |
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 roots 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 38684646959 (PR #23601).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
objectstack-fleet commentedon Oct 15, 2026
Triage: closed
not_planned· not a flake: a semantic conflict, carried on #23473 · triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-15T05:58ZRead fresh. The FAIL lines' reason, from queue build 38682506920 (job 116250083489), is
Error: Cannot layer object 'probe_ticket': the overlay is bound to package 'com.probe.q', but the object is owned by package 'com.probe.p'. That is an assertion of product behaviour onmain, not a timeout.mainrefuses that layering (the package-axis refusals that landed after PR fix(metadata-protocol)!: an uninstall that would drop a table another stored row still serves is refused 409 before anything is removed #23504's reviewed head7d36e8d205). PR fix(metadata-protocol)!: an uninstall that would drop a table another stored row still serves is refused 409 before anything is removed #23504 was queued without a base merge, so its queue build is the first time its test met thatmain.domain:specseat 4 amended its claim on metadata-protocol: uninstalling a package that shares an object with another package now leaves a half-uninstalled package (sys_packages row gone, its row of the shared object stranded) after PR #23464's per-item 409 #23473 (6184860304). The question there is whether metadata-protocol: uninstalling a package that shares an object with another package now leaves a half-uninstalled package (sys_packages row gone, its row of the shared object stranded) after PR #23464's per-item 409 #23473's premise, an object two packages each hold a row of, is still constructible onmain.main. ⛔ No re-queue of the same head.Closed
not_planned: the anchor's cause is named, and it is #23473's.