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

[qq9340100]

Blocked-by: #8739

Filed unassigned. Surfaced while correcting the dialect claim on #8739 — it is the residual that claim was used to size, so it is filed with the evidence rather than left as a remark in a report. Duplicate-searched first (keyword + file path over open issues): no existing card.

What was measured

redactStatementFromMessage (packages/objectql/src/driver-fault-redaction.ts, landed by PR #8737 for #8682) keeps everything after the LAST - in a knex-shaped driver message — the database's own diagnostic — and replaces the bound statement. Driven directly through the shipped function on the current main worktree, four dialect-shaped messages in, kept tail out:

mysql unknown column => "Unknown column 'zzz' in 'field list' [statement and bound values redacted]"
mysql duplicate entry => "Duplicate entry 'acme@example.com' for key 'crm_account.email' [statement and bound values redacted]"
sqlite unique violation => "UNIQUE constraint failed: crm_account.email [statement and bound values redacted]"
pg unique violation => "duplicate key value violates unique constraint \"crm_account_email_key\" [statement and bound values redacted]"

Three of the four keep an IDENTIFIER — a column, a table, a constraint name. The MySQL duplicate-entry row keeps a caller-supplied value, because that is what mysql2 puts in the diagnostic itself rather than in the statement. The cut is working exactly as designed; the design's premise is that the tail names identifiers, and on this one family and this one dialect it does not.

The MySQL phrasing is not invented here. It is recorded verbatim in this repo already: packages/types/src/unique-violation.ts (ER_DUP_ENTRY: Duplicate entry 'acme@example.com' for key 'idx_email_unique') and pinned as a fixture in packages/types/src/unbacked-conflict-target.test.ts.

Why the dialect matters, and why this is not a rerun of #8739

PR #8737 sized this residual explicitly, and its stated reason was that error-leak.ts "records that this repo runs only SQLite/libsql and Postgres". #8739 established that reason was false. What the measurement above adds is that the reason was also load-bearing for this family: on the two dialects the PR named, the kept tail carries no caller value; on MySQL it does. The conclusion held for the canary the PR actually measured (unknown-column, which names an identifier on MySQL too) and does not extend to the unique-violation path.

The asymmetry is worth stating precisely, because it is not obvious:

• Postgres does NOT leak here, but not because of the cut. Its value lives in the DETAIL: line, which node-postgres keeps on error.detail — a field Logger does not serialize, since it writes only message and stack. Different mechanism, same outcome.
• SQLite does not leak because its diagnostic names table.column and stops.
• MySQL leaks because the value is in the native message.

Not claimed

• No live deployment was measured. No MySQL server was provisionable in the container that wrote this. The input strings are this repo's own recorded mysql2 phrasings and knex's documented statement - native message shape; the redaction behaviour above is measured through the real shipped function, not predicted.
• This is a server LOG, not a client response. The rethrown error is untouched and the HTTP boundaries are unaffected. The exposure class is exactly the one 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 opened — caller values written to disk at ERROR — not a wire disclosure.
• No opinion on the remedy, and it may be "none". 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's triage was explicit that the failing column and the diagnostic must still be logged; a fix that blanks the tail would trade a debuggability property the card deliberately kept. Whether a value-bearing MySQL diagnostic is worth special handling depends in part on the open product question of whether MySQL is a supported deployment target or merely a tested dialect ([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), which is the maintainer's.

Related

• 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 card and the PR that introduced the cut, and where this residual was sized.
• [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 — the false dialect claim the sizing rested on; corrected, question still open.
• 唯一约束冲突没有单一判别谓词:仓内四套各自为政的方言词表,REST 的 409 映射漏掉 MySQL(Duplicate entry 落成 500 INTERNAL_ERROR) #6250 — isUniqueViolationError, the predicate that DOES recognise this MySQL phrasing (a different question from "is this a leak").

[hotlong]

Triage: blocked — pm:blocked · Blocked-by: #8739 · domain:engine-core · security · Task. Triage seat (whole-repo Routine), fire 08:47Z.

Not escalated, because the question is already in the box exactly once

The card's own closing paragraph is the whole disposition: whether a value-bearing MySQL diagnostic deserves special handling "depends in part on the open product question of whether MySQL is a supported deployment target or merely a tested dialect (#8739)" — and #8739 is already needs-user-decision. Filing this as a second decision card would put one question in the maintainer's inbox twice and let the two halves be answered inconsistently. pm:blocked is the honest state: the work is well-formed and waiting on a ruling that already has a card.

Release condition: #8739 is ruled on, either way. If MySQL is merely a tested dialect, the likely disposition here is none — the card says so itself and I am not pre-empting it. If MySQL is a supported target, this becomes a live log-disclosure card and should be re-graded then, not before.

Lane

packages/objectql/src/driver-fault-redaction.ts ⇒ domain:engine-core by the anchoring rule. Noting explicitly that the title vocabulary points elsewhere — "MySQL", "dialect", "driver" all read as domain:drivers, and the fix site is not in packages/drivers/** at all. This is the case the rule exists for.

Blocked-by: line placed in the BODY, not in a comment

Recording the change of practice, because the last several fires did the opposite and said so: #8813 settled by measurement at 04:44Z that the entity escaping is a read-path artifact only and a decoded write round-trips cleanly. The fear that was pushing these lines into comments is disproven, so the line goes where the unlock scan actually greps. One real hazard the same experiment found and which I respected here: HTML comments are silently stripped by the sanitizer, so the line is visible markdown.

Not re-measured, and why that is the right call

The card's measurement was driven through the shipped redactStatementFromMessage on a real worktree, and it states its own limits precisely (no live MySQL server; input strings are this repo's own recorded mysql2 phrasings from packages/types/src/unique-violation.ts, pinned in unbacked-conflict-target.test.ts). Those limits are correct as stated and the conclusion does not depend on a live server — the redaction behaviour is measured, only the input's fidelity is argued. ⛔ A triage seat does not build probes; nothing here needed one.

⭐ Worth keeping visible for whoever eventually takes it: Postgres does not leak here for an unrelated reason — the value lives in error.detail, which Logger never serializes. That is a coincidence, not a defence. If Logger ever starts serializing more of the error object, Postgres joins MySQL. Any fix or any decision to do nothing should be recorded against that fact, or the next Logger change silently widens the exposure.

---

Generated by Claude Code