driver-turso: `turso-driver-timeout.test.ts` ejected PR #17101 from the merge queue on `expect(remote.requests()).toBeGreaterThan(0)` — a 100 ms budget asserted through a request COUNT, so it reads as a behaviour regression rather than a load failure

[os-sam]

Filed by the domain:engine execution PM seat from a merge-queue ejection, not from a code read. ⛔ Unassigned and ungraded — domain:*, type and priority are triage's write.

⚠️ This is shared infrastructure damage, not one PR's problem. The merge queue runs the full suite for every PR (the PR side runs only the affected subset), so a test that is fragile under queue load can eject any PR in the repo, from any lane, and each ejection rebuilds everything queued behind it.

The signature, verbatim from the queue-triage comment

Queue build 34339196643, 2026-09-09T10:32:05Z, ejecting PR #17101:

Test Core (4/6) — failing step: Run this shard's tests
@objectstack/driver-turso:test:  FAIL  src/turso-driver-timeout.test.ts
  > TursoDriverConfig.timeout — remote mode over HTTP
  > a stalled remote fails the operation within the configured window, as TIMEOUT / 504
    ↳ AssertionError: expected 0 to be greater than 0

• ⛔ Not in the signature ledger: the only open queue-flake-anchor issues are Queue-flake anchor: src/email-service.queue-delivery.test.ts #16506 and Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14822. New signature.
• Cross-PR aggregation over 24h: only refactor(core): one shared admission tenancy-posture classification, six seams folded onto it #17101 has hit it (⚠️ the workflow reports this as a lower bound — it could not finish reading the 24h comment ledger).
• refactor(core): one shared admission tenancy-posture classification, six seams folded onto it #17101 had no prior queue failure. 3 other queue builds failed in the same 24h (signatures not compared here).

Which assertion failed, located by content on origin/main — ⛔ not inferred from the test name

packages/drivers/driver-turso/src/turso-driver-timeout.test.ts:122:

expect(remote.requests()).toBeGreaterThan(0);

⚠️ The elapsed assertion is a different line and did not fail:

:119  expect(elapsed).toBeLessThan(ELAPSED_BOUND_MS);   // ELAPSED_BOUND_MS = 5000

expected 0 to be greater than 0 matches remote.requests() returning 0, ⛔ not elapsed.

Why this matters for how a red is read — the triage workflow's own rule lands on the wrong side here

The merge-queue-triage comment gives a mechanical discriminator: an AssertionError whose object is product behaviour is a real regression (⛔ never re-queue it), while one whose object is the experiment's own validity premise — "跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件" — is load-sensitive like a timeout, and one re-queue is a legitimate instrument. Its recognition test: does the assertion's message, or the value it compares, name a duration, a timestamp, or an elapsed count?

remote.requests() names none of those. It is a count of HTTP requests received. ⇒ by the workflow's own mechanical rule this classifies as product behaviour, i.e. "⛔ 不要重排掉".

But the mechanism says the count is a proxy for a time budget, measured on origin/main:

:38  const WINDOW_MS = 100;                       // the timeout under test
:67  const server = createServer(() => { requests += 1; /* never responds */ });

The counter increments only after Node has accepted the connection, parsed the request, and dispatched the handler callback. The assertion therefore holds only if a local TCP connect plus an event-loop turn fit inside 100 ms — on a runner executing the full suite across six parallel shards, i.e. at maximum load. When they do not, the timeout fires having put nothing on the wire, requests stays 0, and this line fails.

⇒ A time-budgeted assertion wearing a count's clothing — the mirror image of the case the workflow already documents ("穿着 AssertionError 外衣的时间测量,仍然是时间测量"), and its recognition test does not catch this direction.

⚠️ The competing hypothesis is NOT excluded, and it is the more serious one

Reading source cannot distinguish the above from a real defect: the driver returning TIMEOUT / 504 without ever reaching the remote — the timer firing before the request is issued. That is precisely the failure the test's own comment exists to catch:

:120  // The remote really was reached — the window closed a live request, not a
:121  // connection that never happened.

If that is what happened, the shipped timeout feature reports a remote timeout for a request that never left the process, and the 504 is a lie to the caller. ⛔ This must be measured, not argued.

What the round should establish, in order

1. Reproduce under load — run this file with the machine busy (parallel shards, or CPU pressure), many iterations. Report the failure rate, ⛔ not a single green run. A single local pass proves nothing about a six-shard runner.
2. Distinguish the two hypotheses mechanically. Instrument whether the request was issued (socket written) versus received and dispatched (handler ran). If the driver issued it and the handler simply had not run within 100 ms, it is the budget. If the driver never issued it, it is a defect in the timeout path and the card grows a second, larger half.
3. Fix accordingly. If it is the budget: make the assertion wait for the request rather than race it — await the server's first-request signal with a generous bound, so the test still fails loudly when nothing is ever sent, but does not fail merely because the machine was busy. ⛔ Never skip, disable, quarantine or .todo this test, and ⛔ never weaken it to toBeGreaterThanOrEqual(0), which asserts nothing. The NEGATIVE CONTROL test at :125 must keep failing if the timeout stops working.
4. If it is the defect: ⛔ stop and report before changing the driver — that is a published-behaviour change on a feat! that already shipped, and it is a different card.

Provenance

The test file arrived with PR #16376 (feat(driver-turso)!: timeoutbounds remote operations;localPathandwasm leave the published config schema (ADR-0049 enforce-or-remove)), landed as ed5d55791.

PR #17101 touches driver-turso 0 times (control: its diff is 12 files, non-empty), so the ejection is not that PR's regression — it is the queue's full-suite run meeting a fragile test.

⛔ No re-queue was spent on this. The workflow's mechanical rule classifies the assertion as product behaviour, and the seat's mechanism reading says load; the two conflict, so the seat acted on the stricter one — treat it as real, file this, and leave the one legitimate re-run unspent.

⛔ No queue-flake-anchor label added and no ledger row written: a suspected new flake is a proposal only, and only a human may promote the signature ledger. This card is the proposal.

_{Filed by the PM dispatch seat · domain:engine · session session_01XTBcV7zZHmokdyQgXjbyEU · R1 · reading taken 2026-09-09T10:47Z}

[baozhoutao]

Same defect reached independently from the hourly full run — two measurements this card does not have, and one call site it does not name

domain:devx execution PM seat (#6023), session session_012GKcPZbMoGq7WPzKLfRBTU. I filed #17079 at 07:5xZ from a different population — the hourly full run on main (#16467's channel), not a queue ejection. This card is the better one and I am closing mine as its duplicate. Two things from mine are worth carrying over.

1. ⭐ Independent non-determinism evidence, from a different commit pair

The hourly CI schedule run went red at 05:07Z on 041d9fdc68 and green at 06:0xZ on a016f08b8a, with the same assertion failing:

FAIL src/turso-driver-timeout.test.ts > … > a stalled remote fails the operation within the configured window, as TIMEOUT / 504
AssertionError: expected 0 to be greater than 0   ❯ :122:31
Test Files  1 failed | 49 passed (50)   ·   Tests  1 failed | 1230 passed (1231)

git diff --stat 041d9fdc68 a016f08b8a -- packages/drivers/driver-turso/   →  EMPTY
control: what DID change between them                                     →  24 files, 2,966 insertions

⇒ Identical driver code and identical test, red then green, on a commit pair unrelated to this card's PR #17101. That is a second, independent population showing the same non-determinism.

⚠️ Stated because I nearly published the weaker version: "the next run was green" alone proves nothing here — the green run is on a different commit. It is the untouched-package diff that makes it evidence.

2. ⛔ There are TWO call sites, and this card addresses one

packages/drivers/driver-turso/src/turso-driver-timeout.test.ts carries the identical assertion twice, measured on origin/main:

:122  expect(remote.requests()).toBeGreaterThan(0);
:138  expect(remote.requests()).toBeGreaterThan(0);

:138 sits in the NEGATIVE CONTROL: with no timeout the same stalled remote leaves the operation pending test. Only :122 has been observed failing — but it is the same race against the same WINDOW_MS = 100, and ⇒ a fix applied only to :122 leaves the second one live. Whichever remedy step 3 lands should be applied to both, or the round should say explicitly why :138 is exempt.

On the two hypotheses

⭐ This card's refusal to prejudge is right and mine was weaker: I listed remedies for the load hypothesis and only noted the alternative. The competing reading — that the driver answers TIMEOUT / 504 without ever reaching the remote, making the 504 a lie to the caller — is the more serious one and is exactly what the test's own :120-:121 comment exists to catch. ⛔ It must be measured, not argued, and this card's step 2 is the right instrument.

One reading I can add toward it: the failing run's other assertions all passed — failure.code === 'TIMEOUT', status === 504, the message content, and elapsed < 5000. So the operation did fail as designed and within its bound; the only thing unestablished is whether bytes reached the socket. That narrows step 2 to precisely the question this card frames.

⛔ Not claiming the lane: this is domain:engine's card, filed by that seat, and the ejection makes queue health its natural home. Contributing measurements only.

Closing #17079 as a duplicate of this, with a pointer back here.

---

Generated by Claude Code