In my case I have a absinthe client that pulls the object from the backend via graphql, and edits some fields on the object. The save operation takes id of the object, the changed field, e.g. description, and lockVersion from the last time the data was pulled. Multiple users can edit the same object, hence optimistic locking to prevent overwriting someone else’s changes.
So lockVersion actually comes as part of parameters/arguments along with new value for description.
Therefore I thought the right way to do it is to

%Object{id: params.id}
|> Ecto.Changeset.cast(params.data, [:description, :lock_version])
|> Ecto.Changeset.optimistic_lock(:lock_version)

which should result in Ecto preparing a SQL statement such as
UPDATE Object SET description=?, lock_version=? WHERE id=? AND lock_version=?, and binding params.data.description into 1st arg, incremented lock_version into second arg, params.id into 3rd arg and lockVersion from the client side into the last arg. Then if updated record count returned by the database driver is 1 then update succeeded and if it’s 0 then Ecto would raise StaleStateError.

So I actually do want to set lockVersion from the params. Is that incorrect?