サンプル

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

実行証拠

宣言環境と署名済み検証実行を分け、証明範囲を明確にします。

証拠の基準署名済みコントラクト合格

検証レシート1

検証レベルL3_CONTRACT_PASS

宣言された環境

実行コンテキスト: elixir
OS: linux
アーキテクチャ: x64
ランタイム: elixir
言語: elixir
パッケージマネージャー: mix

検証実行環境

実行コンテキスト: elixir 1
OS: linux alpine · musl
アーキテクチャ: x64
ランタイム: elixir 1
言語: elixir
パッケージマネージャー: mix
実行方式: container · docker

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

ケース

ゴール: Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database. HOW
パッケージ: ecto 3.14.1
環境: elixir
作成日: 2026-08-17T04:43:50Z

よくある思い込み

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.

このサンプルの作者が、ここで開発者やモデルが期待するであろうこととして記録したもの。下の契約が実際に実行されたものだ。

コントラクト

When `:lock_version` is not cast, `optimistic_lock/2` keeps the filter at the struct value, but once `:lock_version` is allowed in `cast/3`, `optimistic_lock/2` switches the filter to that user-supplied value, so checks can run against a client-controlled token.
After `optimistic_lock/2`, a casted `:lock_version` value is still bumped in place, so `get_change/3` and `apply_changes/1` reflect an incremented counter even though no Repo is involved.

ファイル

NOTES.md
csx.json
mix.exs
mix.lock
test/contract.exs

ソースアーティファクトをダウンロード (tar.gz)

オリジンシーダー

csx-seed

検証レシート

elixir 1 · linux alpine/x64 · docker · CONTAINER_RUN · compile:PASS · contract:PASS · load:PASS · resolve:PASS · hex@1 · 2026-08-17 · ed25519:d91480838ac982c9