updateAll with multiple includes silently updates 0 rows on MySQL

[bpamiri]

Symptom

UpdateAllIncludeJoinSpec → "updateAll with multiple includes updates matching rows" fails on MySQL only: Expected [1] but received [0]. Every other engine × database leg passes it (SQLite, Postgres, SQL Server, H2, CockroachDB — verified in matrix run 28809821005, lucee7 leg artifacts).

In plain terms: updateAll() with an include= spanning multiple associations appears to update zero rows on MySQL where it updates the matching row everywhere else — a silent bulk-update no-op on a mainstream database.

Dating

• The spec landed in fix(model): scope-arg denylist removal, select= dev warning, per-WHERE Migration + ON-split fixes #3011 (efffbc360, 2026-06-11, the per-WHERE Migration + ON-split fixes).
• The failure is present in the 2026-06-28 scheduled matrix (lucee7+mysql: 4619 pass / this 1 fail), 2026-07-05, and 2026-07-06 runs — red on every weekly run since the spec existed.
• efffbc360 is contained in v4.0.4 and v4.0.5 — not a new regression; shipped releases already behave this way.

Why nobody saw it

Two blind spots stacked: the compat-matrix engine jobs are continue-on-error (the run banner says "success" while legs fail), and required PR CI runs Lucee 7 + SQLite only. Worth fixing the visibility problem alongside the bug — a matrix leg failing a non-soft-fail database should probably fail the job.

Where to look

MySQL's multi-table UPDATE ... JOIN syntax differs from the ANSI/other-adapter forms (no FROM clause; joins live in the UPDATE clause itself; alias handling differs). The multi-include path from #3011's ON-split work is the likely divergence point — the single-include case passes on MySQL, so it's specifically the second join that breaks row matching.

Repro

tools/test-matrix.sh lucee7 mysql
# or directly: /wheels/core/tests?db=mysql&format=json&testBundles=wheels.tests.specs.model.UpdateAllIncludeJoinSpec

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear "what happened / what I expected": updateAll() with a multi-association include= silently updates 0 rows on MySQL (Expected 1 but received 0) where it updates the matching row on every other engine/DB (SQLite, Postgres, SQL Server, H2, CockroachDB all pass). Reproducible in isolation via tools/test-matrix.sh lucee7 mysql.

Suspected layer

model — the ORM query-generation path for updateAll. (Note: there is no .ai/wheels/model/ doc; canonical patterns live in the CLAUDE.md Model Quick Reference and query-builder anti-patterns.)

Fix sketch

The MySQL branch in vendor/wheels/model/update.cfc (lines ~83-100) builds a multi-table UPDATE <table> <joins> SET ... by concatenating each association join fragment from $expandedAssociations(), unlike other adapters which emit a plain UPDATE <table> SET. MySQL multi-table UPDATE ... JOIN syntax differs (no FROM, joins live in the UPDATE clause, alias handling differs), and the single-include case passes — so the defect is specifically how the second join and its ON clause are assembled/aliased for the multi-include case. Likely change is in that MySQL join-concatenation block and possibly the join / ON-split fragments produced by $expandedAssociations (from PR 3011) and $addWhereClause. propose-fix should reproduce against MySQL, not SQLite, since the failure is MySQL-only.

Confidence: medium

The report is unusually precise about the failing spec and suspected code path, but this is inherently a cross-engine concern (MySQL UPDATE ... JOIN diverges from the ANSI/other-adapter forms) — the cross-engine auto-downgrade rule caps confidence at medium, and the fix must be validated on MySQL specifically.

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (database-dialect-specific SQL generation — the MySQL UPDATE ... JOIN branch in vendor/wheels/model/update.cfc), and the bot's safety net requires a human in the loop before any code is written.

Two blockers, both grounded in the command's TDD invariant:

1. Cross-engine / per-dialect code path. The failure is MySQL-only; the fix must live in the MySQL branch (ListFind('MySQL', local.dialect)), which builds a multi-table UPDATE <table> <joins> SET ... unlike every other adapter (Postgres uses FROM, SQLite/H2/Oracle use WHERE EXISTS, MSSQL uses FROM ... JOIN). The triage comment already invoked the cross-engine auto-downgrade rule and capped confidence at medium for exactly this reason.

2. Unverifiable in the bot environment. bash tools/test-local.sh runs SQLite only — where this spec already passes, because the MySQL branch never executes under SQLite. Reproducing the actual Expected [1] but received [0] failure needs tools/test-matrix.sh lucee7 mysql (Docker), which is not available/approvable here. That means the mandatory TDD loop — write failing spec → confirm it fails → implement → confirm it passes — cannot be honestly satisfied for a MySQL-only defect.

I traced the code path and have candidate root causes (e.g. the join fragments are concatenated with no separator at update.cfc:92; nested-transaction visibility inside the test's outer cftransaction; LEFT JOIN + right-table WHERE semantics; unqualified SET-column quoting), but I could not determine which one actually produces the silent 0-row result without running against MySQL. Shipping a speculative change to SQL generation and claiming a verified failing→passing cycle would be dishonest.

Recommended for the human picking this up: reproduce with tools/test-matrix.sh lucee7 mysql (or the targeted bundle /wheels/core/tests?db=mysql&format=json&testBundles=wheels.tests.specs.model.UpdateAllIncludeJoinSpec), dump the generated SQL from the MySQL branch of updateAll(), and confirm the divergence before editing. Worth pairing with the visibility fix the issue notes — a non-soft-fail matrix leg failing should fail the job, not ride under continue-on-error.