objectql: the value-bearing-diagnostic list in `driver-fault-redaction.ts` has one entry and no way to notice a second is missing (observation)

[os-zhuang]

Filed unassigned from #8823's implementation (PR pending). Observation-class: nothing here is measured off a thrown error, which is exactly why it is a card and not a patch. Duplicate-searched first (keyword + file path over open issues): no existing card.

What #8823 established

redactStatementFromMessage (packages/objectql/src/driver-fault-redaction.ts) keeps the database's diagnostic after the statement cut, on the premise that the diagnostic names identifiers. #8823 measured one family where that premise is false — MySQL's ER_DUP_ENTRY (1062) inlines the conflicting value — and its fix redacts that one value slot while keeping the index name.

That fix introduces a small list of value-bearing templates. It has exactly one entry, and the source states the rule for adding a second: a dialect's spelling goes in once measured off a thrown error, never from a reading of the manual (the standing rule in packages/types/src/unique-violation.ts).

The gap this records

The list is correct and the rule is right. What does not exist is any way to notice a missing entry. Nothing measures whether a diagnostic a driver produced carries a value; the single entry got there because a human read one template closely, and the next one will need the same accident.

Two families that read like candidates, both from the manual and therefore deliberately NOT added by #8823's PR:

• MySQL ER_TRUNCATED_WRONG_VALUE_FOR_FIELD (1366) — Incorrect integer value: 'abc' for column 'age' at row 1. The first slot is the caller's value; the second is an identifier.
• Postgres invalid input syntax for type integer: "abc" — a caller value on error.message, unlike the unique-violation case where Postgres' value sits on error.detail and is saved only by Logger not serializing that field.

⛔ Neither is a claim that these leak. Neither has been raised off a live server here, so under the standing rule neither may be added, and both may be phrased differently in practice than the manual says.

What would actually close this

Not "add the two above". Probably one of:

• a probe that raises each candidate family against the live MySQL/Postgres services CI already stands up, and records the real phrasing — which converts these from manual-reading to measurement and makes them addable;
• or a decision that the redactor's contract should invert for this one slot (keep an allowlist of identifier-shaped tails rather than a denylist of value-bearing ones) — a wider contract change with its own cost, since over-matching deletes the diagnostic an operator came for.

The second is a real design question and is not something #8739's ruling covers, which is why this is filed rather than decided.

Related

• The #8682 write-path redaction keeps a caller's VALUE in the log on MySQL — Duplicate entry 'acme@example.com' for key … survives the cut, measured through the shipped function #8823 — the card this came out of; its scope was the one measured phrasing.
• Undeclared fields still reach the driver: beforeInsert hooks run and an auto-number is consumed before the request is refused, and the whole INSERT with its values is logged at ERROR (17.0.0 GA) #8682 / PR fix(objectql): refuse undeclared insert fields at the schema, and keep bound values out of the write-path logs (#8682) #8737 — the cut, and the debuggability property it deliberately kept.
• [finding] error-leak.ts asserts "nobody here runs" MySQL — but CI stands up a live mysql:8.0 for a required check, and the claim is load-bearing for security reasoning #8739 / PR fix(types): teach the internal-leak predicate MySQL's three error templates (#8739) #9030 — MySQL as a supported deployment target, and the leak predicate's MySQL limbs (a different predicate; it answers "is this a dump?", not "which span is a value?").

[os-zhuang]

Triage (first-touch grading): lands in packages/objectql → domain:engine-core; promoted finding → pm:queue, type Task — scoped to the MEASUREMENT PROBE ONLY.

In scope: raise the two candidate families (MySQL ER_TRUNCATED_WRONG_VALUE_FOR_FIELD 1366; Postgres invalid-input-syntax) against the live MySQL/Postgres services CI already stands up, record the real phrasings, and add value-slot entries only for what is actually measured — per the standing rule (measured off a thrown error, never from the manual).

Out of scope: the allowlist-inversion redesign of the redactor contract. That is a design question and stays unopened unless the probe's measurements show the denylist shape cannot keep up — in which case report, don't decide.

Rationale for promoting over holding: the redaction family has repeated recent investment (#8823, #8739/#9030), and the Postgres candidate would place a caller value on error.message, which the current cut keeps — converting these from manual-reading to measurement is cheap while the CI legs exist. Premise re-verified on origin/main: driver-fault-redaction.ts still lists the single ER_DUP_ENTRY family.

Size/model suggestion: M, opus.

---

Generated by Claude Code

[os-zhuang]

PM claim · seat pm-dispatch · session 17d48cbe-d3e0-562b-95a3-e2653a9bd9fb · branch claude/issue-9160-value-bearing-diagnostic-probe

Claiming for dispatch. Batch 5, card 4 of 4. Scope is deliberately half this card.

裁决 — not re-litigable

1. Dispatched scope = the measurement half only. Build the probe: raise the candidate diagnostic families against the live MySQL/Postgres services CI already stands up, and record the real phrasing that comes back. The card's own framing is the ruling — this turns "读手册" into "测量", which is the single thing that makes any future entry addable under the standing rule.

2. ⛔ The contract inversion is OUT OF SCOPE. Whether the redactor should keep an allowlist of identifier-shaped tails instead of a denylist of value-bearing ones is a real design question, is explicitly not covered by [finding] error-leak.ts asserts "nobody here runs" MySQL — but CI stands up a live mysql:8.0 for a required check, and the claim is load-bearing for security reasoning #8739's ruling, and is the reason this was filed rather than decided. It is a maintainer call. Do not implement it, do not prototype it, do not pre-shape the probe to make it inevitable.

3. ⛔ No entry may be added from a manual. That is the standing rule in packages/types/src/unique-violation.ts and it is not relaxed by this card. If your probe raises a family and records phrasing that shows a value slot, adding that entry is in scope — the recorded output is the warrant. If your probe cannot raise it, the entry does not go in, and "we believe it leaks" is a finding, not a patch.

4. A zero is not a measurement without a positive control. The probe must first raise MySQL ER_DUP_ENTRY (1062) — the one family already known value-bearing and already encoded — and reproduce the phrasing the current single entry matches. If the known-present neighbour does not answer, your instrument is broken and every other result is uninterpretable. Report the control's output explicitly, whatever else you find.

PM 机制假设 — falsifiable, measure them

• CI already stands up live MySQL and Postgres services. The card asserts this; I have not verified it this shift. Find the workflow and say which one. If no live service exists, the shape of the close changes — stop and report, do not stand up new infrastructure on your own authority.
• The two named candidates are raisable from the driver layer (ER_TRUNCATED_WRONG_VALUE_FOR_FIELD 1366; Postgres invalid input syntax for type integer). If a family cannot be provoked through the driver's own code path, say so — an unraisable family is a documented negative result, which is a real outcome for this card.
• The manual's phrasing differs from what a server actually emits. That is the premise of the whole exercise. Record verbatim, including the case where it matches the manual exactly — that is informative, not a null result.
• Postgres' unique-violation value sits on error.detail, which ObjectLogger.write does not serialize (packages/core/src/logger.ts:343). The #8682 write-path redaction keeps a caller's VALUE in the log on MySQL — Duplicate entry 'acme@example.com' for key … survives the cut, measured through the shipped function #8823's PR recorded that this is "coincidence, not a defence". If your probe shows a candidate whose value lands on error.message instead, that distinction is the finding — call it out.

Route

• Worktree-first, per repo, before your first edit.
• Surface: packages/objectql/src/driver-fault-redaction.ts and whatever probe/test file the repo's live-service tests live in. redactBoundStatement has exactly 3 call sites, all logger.error in engine.ts (8780, 9873, 10669) — ⛔ do not add a fourth.
• Changeset per repo rules. Draft PR. ⛔ Never merge your own PR.
• ⛔ Never raise a TEST_DEBT ledger entry to get past a failure; ledgers may only shrink.

Model tier

Clause ② judged not triggered: this changes log-redaction output, not contract accept/reject behaviour, and touches no packages/spec/**, no error-code ledger, no *.zod.ts. Dispatching at sonnet. ⚠️ Fence, and I want this taken literally: if the work starts to touch the redactor's contract — the allowlist/denylist inversion, a new error code, or anything under packages/spec/** — stop and report before writing it. That is clause-② territory and this seat has already breached that clause twice this shift (#9111, #9157). Do not let a probe grow into a contract change.

---

Generated by Claude Code