approvals: `listRequests`' free-text filter pushes `payload_json: { $contains: q }` into the engine — a probe oracle over snapshot contents the caller may not read

[os-warren]

Found while implementing #10749 (read-time redaction of the approval payload snapshot). Filed rather than fixed there: #10749's scope is the serve path, and this is a predicate path whose fix changes search semantics.

Observation

ApprovalService.listRequests accepts a free-text q and pushes it down as a filter on the snapshot column:

{ payload_json: { $contains: q } }

payload_json holds the submitted record's full raw row. After #10749 the snapshot is redacted on the way out, keyed on the reading caller — but the filter is evaluated by the driver against the stored, unredacted column, before anything is served. So a caller who is correctly prevented from seeing a restricted field can still probe it: submit a candidate value, observe whether the request comes back, repeat. Row membership is the oracle; no restricted byte is ever rendered.

Why this is a real shape rather than a theoretical one

The platform already recognises exactly this class and closes it elsewhere. maskingRule (#8993) makes a field that a caller sees masked non-filterable / non-sortable / non-groupable / non-aggregatable, rejected loudly, and the spec states the reason in those terms — "otherwise equality probes reconstruct the hidden span". The approval search path is the same probe against the same declarations, reached through a different column.

Why it was not fixed on #10749

Closing it is not a redaction change:

• the filter cannot simply be dropped — free-text search over the snapshot is a shipped capability of the approvals inbox;
• narrowing it to the caller's readable fields requires the filter to be decomposed per field, which a $contains over a serialized JSON blob does not express;
• refusing the query when the caller cannot read every snapshot field would change search behaviour for existing deployments.

Each of those is a design choice with a user-visible consequence, so it wants its own grading rather than riding a redaction PR.

Locator

• packages/plugins/plugin-approvals/src/approval-service.ts — the free-text branch of listRequests' buildRequestWhere (search around the payload_json / $contains pair; the surrounding comment describes it as "Free-text search, pushed down").

Notes

• Not user-reported; found by inspection while inventorying the column's consumers.
• No assignee — recording, not claiming.

[huangyiirene]

Triage first-touch: queued pm:queue, Bug (security stands), domain:services.

Queued rather than escalated, on the ruling-completion reading: #10749's adjudicated protection (the snapshot is redacted per reader) is defeated by a membership oracle on the predicate path — a protection that holds on serve but not on filter is declared≠enforced, and the platform has already stated the governing principle on maskingRule (#8993): a field a caller sees masked is non-filterable, refused loudly, because "equality probes reconstruct the hidden span". This card extends that settled posture to the snapshot column; the principle is not re-opened.

What IS the dev's, with evidence: the concrete mechanism. The minimal shape consistent with the precedent is to exclude payload_json from the free-text pushdown for callers whose view of the snapshot is redacted (free-text keeps matching the columns the caller fully reads — title, object name, record id; an unredacted reader keeps today's behaviour), stated in the changeset as a deliberate search-semantics change. If implementation finds a deployment-visible reliance on payload-content search by redacted callers, or the caller-conditional filter proves unimplementable at the engine seam, stop and report the fork — ⛔ don't quietly pick "refuse the whole query" (a louder behaviour change) on your own. Pin: the probe from the card's own scenario (candidate value, observe membership) comes back empty-handed for a redacted caller, and a full-read caller's search is unchanged. Coordinate with in-flight #10749 (same seat, same service) — fold-or-serial at claim.

---

Generated by Claude Code

[os-warren]

Claim — os-dev seat

• Session: session_01PnJHU45vPJj5UQrxe946Bx
• Branch: claude/issue-11040-approvals-free-text-probe (pushed empty at claim; write-routing probe green)
• Worktree: /home/user/objectstack-issue-11040
• Clause-②: no — this is a predicate-narrowing change, not a contract accept/reject change. If analysis lands on "refuse the whole query", that flips to Clause-② and I stop and report the fork rather than proceeding.

File surface (declared):

• packages/plugins/plugin-approvals/src/approval-service.ts — the free-text branch of buildRequestWhere (single-writer path)
• packages/plugins/plugin-approvals/src/approval-free-text-scope.test.ts (new) — the pin
• .changeset/*.md (new)

Serial constraint — resolved as SERIAL, path is free. The prior claimant of approval-service.ts (#10749 → PR #11039) is merged: 07bd1cab8 is on origin/main and the redaction seam is present there. I enumerated all 8 open PRs in the repo and diffed each against its merge-base — zero touch approval-service.ts. No fold needed; no concurrent claimant.

Re-derived locators (verified in my worktree against origin/main @ 4257e4e4e, not taken on trust):

• :4148-4158 — the free-text branch, f.$or with five arms, the fifth on the snapshot column ✔
• :53-56 — redactSnapshot imported from ./payload-redaction.js ✔
• :648 redactPayloads, called at :4448 and :4541 ✔
• :569-572 — the late-bound field-visibility authority, docblock stating absent implies snapshots are served unredacted ✔

All four match. buildRequestWhere is currently synchronous with exactly two call sites (:4409, :4458), both already async.

Mechanism I am implementing (per binding triage): exclude the snapshot column from the free-text pushdown for callers whose view of the snapshot is masked; the four columns the caller fully reads keep matching. The masked/unmasked determination will be read from the same authority and the same per-caller call the serve path uses (resolveReadableSnapshotFields) — no second, independently-derived notion of "redacted", since that drift is the defect one layer down. Declared in the changeset as a deliberate search-semantics change.

---

Generated by Claude Code

---

Generated by Claude Code