Ecto.Repo.update_all/3 does not raise Ecto.StaleEntryError on locked rows

Answer

Yes. Repo.update_all/3 leaves the optimistic lock column unchanged and does not raise Ecto.StaleEntryError. A bulk update can silently overwrite a row that was modified via Repo.update/3.

Confirmed facts

Repo.update_all/3 executes a direct SQL UPDATE and bypasses Ecto.Changeset. Validations, callbacks, and the optimistic-lock logic implemented in changesets are not invoked. The @optimistic_lock schema option is only enforced on changeset-based operations such as Repo.update/2 and Repo.insert/2.

Likely explanation

Because update_all builds SQL directly from the query and update map, no lock value is read, compared, or incremented. Therefore a concurrent Repo.update_all/3 can write to a row whose lock version has advanced via a changeset path, producing a lost update with no error. This bypass is in Ecto core, so the absence of automatic lock handling is consistent across adapters, though exact SQL shape and return values vary by adapter and Ecto release.

Steps to verify in your project

1. Inspect the installed Ecto release documentation for Repo.update_all/3 to confirm that it bypasses changesets.
2. Log the generated SQL with Ecto.Adapters.SQL.to_sql to verify the UPDATE does not include the lock column in the WHERE clause unless you added it.
3. Run a minimal reproduction: update a row via Repo.update/2 to bump lock_version, then run Repo.update_all/3 on the same row without a lock predicate and observe that lock_version is unchanged and no Ecto.StaleEntryError is raised.

Recommendation: Avoid Repo.update_all/3 on schemas that rely on optimistic locking unless you manually replicate the lock check and increment in the query WHERE and SET clauses.

One diagnostic detail that changes the recommendation: which Ecto version and database adapter you are running. The core bypass is stable, but the exact API for inspecting and building update_all queries can vary by release.