What
@objectstack/objectql publishes two shared dispatch asserts that in-repo engine doubles must adopt — assertEngineUpdateDispatch and assertEngineDeleteDispatch — and pnpm check:engine-double-contract ratchets their adoption. There is no equivalent for the read side, specifically for the findOne predicate rule.
The real engine (packages/objectql/src/engine.ts → requireFindOnePredicate, #4419) throws on a findOne whose where is absent/empty and which carries no orderBy:
findOne('sys_user') selects no particular record: 'where' is absent or empty and the query
carries no 'orderBy'. findOne applies limit: 1, so this would return an ARBITRARY row ...
Every in-memory double in the repo instead treats an absent filter as "match everything" and answers happily — null on an empty table, an arbitrary row otherwise. So a production call site that violates #4419 reads as working under every unit suite and only fails on a real engine.
What it cost, measured
objectstack#11767 (audience posture, #11739). AuthManager.isBootstrapCreation probed the bootstrap population with adapter.findOne({ model: 'user', where: [] }) inside a try/catch. On a real ObjectQL engine that call throws; the catch { return false; } turned the refusal into "users exist", so the declared first-run bypass never fired and the invite_only default refused the operator's own dev-admin seed. Two required gates went red across every shard (Dogfood Regression Gate 1–3/3, Test Core 1/6 + 2/6) — while a 641-line posture x creation-method matrix over the in-memory double stayed green, including a case literally named "bootstrap: the very first signup is admitted".
Instrumented at the real seam during a dogfood boot:
OSPROBE adapter=true findOne=function
OSPROBE adapter.findOne THREW: findOne('sys_user') selects no particular record ... (#4419)
at _ObjectQL.requireFindOnePredicate (packages/objectql/src/engine.ts:8408)
OSPROBE engine sys_user rows=[] <- zero users; the verdict was false
The call site is fixed in #11767 and pinned by a real-engine test. The class is not: nothing stops the next double-backed suite from certifying the next predicate-less findOne.
Suggested shape
Publish assertEngineFindOnePredicate(query) from @objectstack/objectql beside the two existing dispatch asserts — the producer's own predicate, not a hand-copied re-derivation (that is the hole check:engine-double-contract already names for the delete side) — and extend the ratchet to it. Note the sizing: the adoption wave touches every findOne double in the ledger, so this is its own card, not a rider.
Related
What
@objectstack/objectqlpublishes two shared dispatch asserts that in-repo engine doubles must adopt —assertEngineUpdateDispatchandassertEngineDeleteDispatch— andpnpm check:engine-double-contractratchets their adoption. There is no equivalent for the read side, specifically for thefindOnepredicate rule.The real engine (
packages/objectql/src/engine.ts→requireFindOnePredicate, #4419) throws on afindOnewhosewhereis absent/empty and which carries noorderBy:Every in-memory double in the repo instead treats an absent filter as "match everything" and answers happily —
nullon an empty table, an arbitrary row otherwise. So a production call site that violates #4419 reads as working under every unit suite and only fails on a real engine.What it cost, measured
objectstack#11767 (audience posture, #11739).
AuthManager.isBootstrapCreationprobed the bootstrap population withadapter.findOne({ model: 'user', where: [] })inside atry/catch. On a real ObjectQL engine that call throws; thecatch { return false; }turned the refusal into "users exist", so the declared first-run bypass never fired and theinvite_onlydefault refused the operator's own dev-admin seed. Two required gates went red across every shard (Dogfood Regression Gate1–3/3,Test Core1/6 + 2/6) — while a 641-line posture x creation-method matrix over the in-memory double stayed green, including a case literally named "bootstrap: the very first signup is admitted".Instrumented at the real seam during a dogfood boot:
The call site is fixed in #11767 and pinned by a real-engine test. The class is not: nothing stops the next double-backed suite from certifying the next predicate-less
findOne.Suggested shape
Publish
assertEngineFindOnePredicate(query)from@objectstack/objectqlbeside the two existing dispatch asserts — the producer's own predicate, not a hand-copied re-derivation (that is the holecheck:engine-double-contractalready names for the delete side) — and extend the ratchet to it. Note the sizing: the adoption wave touches everyfindOnedouble in the ledger, so this is its own card, not a rider.Related
findOnethen returns the first row #4419 (the engine rule), finding: 5 engine doubles already call the producer predicate and are still outside the ratchet — oneIDataEngineannotation each would admit them #11850 (a sibling gap in the same ratchet's population).