Skip to content

[finding] Two inline copies of the expected-read-refusal capture still wrap only the engine error channel — one of them can no longer fire since #13273 moved the frame to debug #13325

Description

@os-trump

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).

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions