Found while working #13273; out of that card's scope, filed unassigned. Nothing is red — this is dead suppression plus stale prose, recorded so the next reader is not misled by it.
What changed underneath them
#13273 makes ObjectQL.find pick its failure log level from the cause: a read that positively identifies as "relation does not exist" (isMissingTableError) is logged at debug with a reason: 'table-not-provisioned' meta and no stack; every other read failure keeps error with the stack.
The shared helper packages/runtime/src/expected-read-refusal-noise.ts was updated in that PR: its captureEngine now proxies both error and debug, so the ~20 fixtures that assert silentChannels() keep counting the frame on whichever channel the engine chose. Those are fine.
The two inline copies that were not
captureExpectedReadRefusals was factored out (#10629) precisely to end the per-fixture copies, but two files still carry their own, and both wrap error only:
Suggested disposition
Migrate the first file onto the shared captureExpectedReadRefusals helper — the reason the helper exists, and it carries the debug arm already — and re-measure the header's counts against the current tree while doing it. Leave the second alone.
Low priority: no assertion is weakened, and no noise leaks (the frames are quiet by construction now rather than by suppression).
Found while working #13273; out of that card's scope, filed unassigned. Nothing is red — this is dead suppression plus stale prose, recorded so the next reader is not misled by it.
What changed underneath them
#13273 makes
ObjectQL.findpick its failure log level from the cause: a read that positively identifies as "relation does not exist" (isMissingTableError) is logged atdebugwith areason: 'table-not-provisioned'meta and no stack; every other read failure keepserrorwith the stack.The shared helper
packages/runtime/src/expected-read-refusal-noise.tswas updated in that PR: itscaptureEnginenow proxies botherroranddebug, so the ~20 fixtures that assertsilentChannels()keep counting the frame on whichever channel the engine chose. Those are fine.The two inline copies that were not
captureExpectedReadRefusalswas factored out (#10629) precisely to end the per-fixture copies, but two files still carry their own, and both wraperroronly:packages/runtime/src/notification-schema-conformance.integration.test.ts—captureExpectedAbsentTableNoise().wrapEngine, gated on apendingcounter fed byno such table: <t>driver refusals. Since os migrate plan prints 4 ERROR records with stack traces on a not-yet-migrated database — every one of them is a read whose caller treats absence as a normal answer #13273 those engine frames arrive ondebug, so the recognition arm can no longer match: the frames fall through totarget.debugand are dropped by the fixture's own kernel level. The file stays green because everything it asserts (withheld) is fed by the DRIVER channel, which is untouched. Its header's measurement — "63[sql-driver] DATABASE_ERROR …lines and 63 matchingERROR Find operation failedframes" — is now a historical statement aboutorigin/mainat [finding] Two PASSING@objectstack/runtimetests printAcquire connection errorand ~150 ERROR-levelsql-driver DATABASE_ERRORlines into the shared Test Core log — they were adopted verbatim as a p1 flake signature #10380 time, not about this tree.packages/runtime/src/metadata-list-ambient-vs-bare-transaction.integration.test.ts—engineError.Timeout acquiring a connection, which is not a missing table, so its frame legitimately stays onerrorand itswithheld.engineFindassertion still fires. Named here only so a reader does not "fix" it by symmetry.Suggested disposition
Migrate the first file onto the shared
captureExpectedReadRefusalshelper — the reason the helper exists, and it carries thedebugarm already — and re-measure the header's counts against the current tree while doing it. Leave the second alone.Low priority: no assertion is weakened, and no noise leaks (the frames are quiet by construction now rather than by suppression).