Commit 41f9f46
test(runtime): pin the multi-value cascade-delete path on PostgreSQL, not only SQLite (#18732)
Fixes #18617
Clause-②: no
## What moved
`packages/runtime/src/cascade-delete-multivalue-lookup-real-driver.integration.test.ts`
was the only real-stack pin of the multi-value cascade-delete path —
ObjectQL over a real `SqlDriver` through the protocol data-plane delete
— and it hard-coded `client: 'better-sqlite3'`. That literal is the
named mechanism by which #18172 reached two published releases: every
DELETE of an object targeted by a `multiple: true` reference answered
500 on PostgreSQL, always, and this pin stayed green throughout.
The file now declares a driver axis: the embedded SQLite cell plus a
live PostgreSQL cell provisioned by `OS_TEST_POSTGRES_URL`. Everything
below the one `newDriver()` seam is written once and measured on both.
`packages/runtime/src/expected-read-refusal-noise.ts` had to move with
it, and that is declared here rather than buried — see **In-place
repair** below.
## The measurement — this pin was shown to go RED before it was allowed
to be green
The acceptance bar was not coverage. Ablation:
`SqlDriver.applyJsonMembership` made to answer `false` unconditionally
behind a runtime-evaluated marker, so the cascade probe's `$contains`
falls through to the pre-#17590 substring emitter. driver-sql rebuilt
each leg (runtime's tests resolve `@objectstack/driver-sql` through
`exports`, i.e. `dist/`), and `scripts/ablation-dist-preflight.mjs` used
to prove the mutation reached the artifact before any colour was read.
```
mutate -> on-disk anchor 1, marker 1; blob d25e03f4 vs HEAD 2a17fc1
-> rebuild -> preflight: marker present in 2 built files
-> vitest: 6 failed | 9 passed (15)
ALL SIX failures in "(live postgres)" — ZERO in "(better-sqlite3)"
restore -> git checkout HEAD -- THE_PATH; git diff HEAD empty; marker 0 on disk
-> rebuild -> preflight --absent: marker absent from all 6 built files,
working tree clean against HEAD
-> vitest: 15 passed (15)
-> final blob 2a17fc1 == HEAD blob
```
The fault reproduced byte for byte, on a live PostgreSQL 16.13 with
`timezone=Asia/Shanghai`:
```
[sql-driver] DATABASE_ERROR - the backend refused a read on 'zz_field_zoo' (42883).
... select * from "zz_field_zoo" where "f_lookups" LIKE $1 ESCAPE $2
- operator does not exist: json ~~ text
Serialized Error: { code: '42883', file: 'parse_oper.c', routine: 'op_error' }
```
That asymmetry is the whole card. A `multiple: true` lookup is a TEXT
column on SQLite and a real `json` column on PostgreSQL — measured
through `information_schema` on the live server, and now asserted as
this cell's non-vacuity guard. On TEXT the membership lowering and the
substring lowering are indistinguishable, so no assertion written
against SQLite can separate them. Only the live cell can, and now it
does.
## Without a server
The unprovisioned cell is a NAMED skip that says which variable would
run it, never a silent omission — the suite is emitted either way,
because a cell that emits nothing at all is not a skip and vitest's
summary counts would read as coverage. Under
`OS_EXPECT_LIVE_DIALECT_MATRIX=1` the missing URL is a failure instead,
so a runner that declared it provisioned a server cannot quietly degrade
to SQLite-only. Measured: the full `@objectstack/runtime` suite without
a URL reports `3661 passed | 1 skipped`, and that one skip is this cell
naming itself.
1 parent 30bac28 commit 41f9f46
2 files changed
Lines changed: 409 additions & 14 deletions
File tree
- packages/runtime/src
0 commit comments