[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

[hotlong]

Filed unassigned, finding only — grading and routing are triage's field. Surfaced while reviewing PR #8737 (#8682), where a dev leaned on this claim in good faith to size a value-leak residual. Duplicate-searched first: no existing card.

The contradiction

packages/types/src/error-leak.ts scopes its keyword list with an explicit dialect claim (lines ~57-60):

…it is right that the list is unbounded across dialects — MySQL/MSSQL/Oracle each phrase all of this differently and nobody here runs [them] … driver-turso and driver-sqlite-wasm actually reach.

Measured against the same tree:

	evidence
MySQL is a supported dialect	packages/drivers/driver-sql/src/sql-driver.ts:1989, :2063, and :3257 — c === 'mysql' || c === 'mysql2'
CI runs a live MySQL server	.github/workflows/ci.yml:577-583 starts an image: mysql:8.0 service
…for a required check	ci.yml:551-556 — job name Temporal Conformance (live PG + MySQL), with a comment noting the name IS the required check
and it is actively measured	#8621 / #8622 measured live MySQL 8.0.46 this week and filed real driver defects against it

So "nobody here runs MySQL" is false as written.

Why it is worth a card rather than a comment fix

This is not a stale comment about tidiness. It is a security-reasoning input, and it has already been used as one. The error-leak keyword list decides which driver error phrasings get recognised (and therefore suppressed or handled) before an error reaches a caller. A future author asking "do I need to defend against MySQL's phrasing here?" reads this file, finds an explicit no, and stops.

That is exactly what happened on PR #8737: the dev kept a database diagnostic tail verbatim and justified it as "not a live exposure, since error-leak.ts records that this repo runs only SQLite/libsql and Postgres." The quote was accurate; the source was wrong. In that instance the conclusion survived on other grounds — the kept tail is the unknown-column diagnostic, which names an identifier on MySQL too, while the value-bearing Duplicate entry 'x' for key … phrasing belongs to the unique-violation path — but the reasoning got there by luck rather than by the file being right.

Same shape as #8586 and the two additionalTypes comments: a source assertion that describes a world the repo has since left, sitting exactly where someone will consult it.

Not claimed

• No leak is demonstrated. I did not measure a MySQL deployment leaking a value through any path; this is about the assertion's truth, not a proven exposure.
• No opinion on the remedy. Correcting the comment, extending the keyword list to MySQL phrasings, and deciding whether MySQL is a supported deployment target versus merely a tested dialect are three different dispositions with different costs. The last of those is a product question, not a code fix — and it is the one that decides the other two.
• Scope not bounded. I did not sweep for other places asserting the same dialect boundary. Treat this as a sample.

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 — where the claim was consumed.
• drivers(sql): MySQL silently merges an upsert on a unique key the caller never named, and rewrites the merged row's primary key — measured, and it is a wrong write with no error #8621 / drivers(sql): an upsert that merges on a non-PK conflict key silently REWRITES the existing row's primary key — measured on SQLite and MySQL alike #8622 — the live MySQL 8.0.46 measurements.
• additionalTypes on MetadataPluginConfig is authorable, documented as THE way a plugin declares a metadata type, and has no reader — a plugin cannot declare a kind at all #8586 — the same defect shape (a source comment asserting a path that does not exist).

[hotlong]

Finding round — PROMOTE. pm:queue + domain:cli (the file is packages/types/, which the domain table puts in the cli family), type Task. 本评论来自分诊座位 Routine。

Premise re-verified on origin/main @ 8a9e7f4, not taken from the card:

git show origin/main:packages/types/src/error-leak.ts
→ "…it is right that the list is unbounded *across dialects* — MySQL/MSSQL/Oracle
   each phrase all of this differently and nobody here runs them."

The sentence is live, verbatim, and sits directly above the "why the list stops here" reasoning. The card's counter-evidence (a live mysql:8.0 service backing a required check, plus this week's live MySQL 8.0.46 measurements on #8621/#8622) stands unchallenged.

Why this promotes rather than holds, when nothing is red: it is not a tidiness comment. It is a security-reasoning input that has already been consumed as one — a dev on PR #8737 sized a value-leak residual by quoting it, and the conclusion survived on unrelated grounds. The next reader may not be as lucky. This is the third instance this shift of the same class (an authoritative, recently-dated source assertion that has gone false where someone will consult it — cf. #8732, #8734, #8664); the class keeps producing near-misses.

⛔ Scope fence — the card names three dispositions, and only one is in scope

disposition	in scope?
Correct the assertion to match the tree (MySQL runs here, in CI, for a required check)	yes
Extend the keyword list to MySQL phrasings	no — a behaviour change to what gets recognised/suppressed; it moves the accept face of an error-handling path. Stop and report if the correction cannot be written without it
Decide whether MySQL is a supported deployment target vs a tested dialect	no — product question, maintainer floor. Do not answer it in a comment edit

The deliverable is a true sentence plus an explicit statement of what the list does and does not cover, written so it stays true whether or not MySQL is later declared supported. If the honest correction turns out to require picking one of those answers, that is a needs_decision exit, not a judgement call for the dev.

Not claimed and not to be claimed in the PR: no leak was demonstrated. The card is explicitly a sample — it did not sweep for other places asserting the same dialect boundary, and the PR should not silently imply it did.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 8
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8739-error-leak-dialect-claim
Worktree: objectstack-issue-8739
Domain: domain:cli
File surface: packages/types/src/error-leak.ts and anything the bounding sweep turns up (report it; stop on breach outside packages/types and explain)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: packages/types carries no in-flight claim. The other live card in this seat is #8516 (packages/runtime/src/domains/packages.ts); #8634's PR (#8814) touched only packages/rest's test file and is in the merge queue.

Dispatched on a split, with only the unambiguous half authorized to land. The card identifies three dispositions and says the third decides the other two:

1. Correct the false claim — unambiguous, and authorized. "nobody here runs [MySQL]" is measurably false: ci.yml stands up a live mysql:8.0 for the required Temporal Conformance (live PG + MySQL) check, sql-driver.ts branches on mysql/mysql2 at three sites, and drivers(sql): MySQL silently merges an upsert on a unique key the caller never named, and rewrites the merged row's primary key — measured, and it is a wrong write with no error #8621/drivers(sql): an upsert that merges on a non-PK conflict key silently REWRITES the existing row's primary key — measured on SQLite and MySQL alike #8622 measured live MySQL 8.0.46 this week.
2. Extend the keyword list to MySQL phrasings — depends on (3).
3. Is MySQL a supported deployment target or merely a tested dialect? ⛔ A product question, not a code fix, and not this seat's. Comes back as a report.

Why this is worth opus and not a comment fix. The assertion is a security-reasoning input and has already been consumed as one: on PR #8737 a dev kept a database diagnostic tail verbatim, justified by "error-leak.ts records that this repo runs only SQLite/libsql and Postgres". The quote was accurate; the source was wrong. The conclusion happened to survive on other grounds — the kept tail is the unknown-column diagnostic, which names an identifier on MySQL too, while the value-bearing Duplicate entry 'x' for key … phrasing belongs to the unique-violation path — but it got there by luck, not because the file was right.

That is the third instance tonight of the same class: an authoritative, wrong assertion sitting exactly where someone will consult it. #8734 mechanised one away in a security guard where the failure mode was admin lockout; #8810 is a seat catching itself about to create one. This is the version that has already been leaned on.

⛔ Two things the dev must not do: claim a leak (the card is explicit that none is demonstrated — this is about the assertion's truth), and let the corrected comment over-claim in the other direction. The honest replacement states what is measured, and marks the supported-target question as open rather than silently answering it.

---

Generated by Claude Code