CodeSampleX

Sample

Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database.

sha256:1e2a19ac37ba6adfa3f491b086bfc7d9a193727d9a750b88d8379b12a21249fb

PUBLISHED L3_CONTRACT_PASS MIT-0

Execution evidence

Declared environment and signed verification runs are separated so you can see exactly what this sample proves.

Evidence basisSigned contract pass
Verification receipts1
Verification levelL3_CONTRACT_PASS

Declared environment

Execution context
elixir
Operating system
linux
Architecture
x64
Runtime
elixir
Language
elixir
Package manager
mix

Verification-run environments

Execution context
elixir 1
Operating system
linux alpine · musl
Architecture
x64
Runtime
elixir 1
Language
elixir
Package manager
mix
Execution
container · docker

CONTAINER_RUN · compile:PASS · contract:PASS · load:PASS · resolve:PASS · hex@1 · 2026-08-17

Case

Goal
Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database. HOW
Packages
ecto 3.14.1
Environment
elixir
Created
2026-08-17T04:43:50Z

Commonly assumed

A competent Ecto user expects `optimistic_lock/2` to protect updates using the row's current stored `:lock_version`, and that unsafely cast `:lock_version` params cannot influence the value used in the conflict check.

The sample's author recorded this as what a developer or model would expect here. The contract below is what actually ran.

Contract

Files

Download the source artifact (tar.gz)

Origin Seeder

csx-seed

Verification receipts