Which writes escape a version guard, and how do you keep the guard meaningful when such writes are needed?

## What the guard covers, precisely An optimistic version protects a row only through the path that maintains it: the layer emits an update for an object it is tracking, binds the loaded version into the `WHERE` clause, and advances the column in the same statement. Everything outside that path is unguarded by construction. This is not a defect of the mechanism - it is the boundary of it, and knowing where the boundary runs is most of the senior-level content here. ## Set-based writes A statement that changes many rows in one go - archive everything older than a date, reprice a category, flip a status - never loads those rows into memory, so there is nothing to compare against. Two distinct problems follow. 1. **The write itself is unguarded.** It overwrites whatever is there, including an edit someone committed a second ago. That is often exactly what was wanted, but it should be a decision, not an accident. 2. **The column is left stale.** If the statement does not advance the version, a reader who loaded a row before the bulk write still holds a version that matches the row - so their later write passes the guard and quietly reverts the bulk change. The second problem is the nastier one, because it turns a set-based write into a *silent* lost update for anyone who was already holding the row. ## Writers that never touch the layer at all The same reasoning covers a widening circle: - Statements written by hand for a data fix or a report-driven correction. - Another service, a scheduled job, or an import writing the same tables. - Engine-side rules that modify a row as a side effect of another write. - Anything restoring rows from a copy of the data. Each of these can change a row's contents while leaving its version untouched, and each therefore blinds every optimistic reader that was already holding it. ## Keeping the guard honest | Situation | What to do | |---|---| | Set-based update of guarded rows | Include `version = version + 1` in the statement so holders of old versions are invalidated | | Loaded copies exist in the same unit | Run the set-based write first, or drop the tracked copies afterwards and re-read | | A write path outside the application | Give it the same increment rule, or accept and document that it is a break in the guard | | A data fix by hand | Advance the version too; it costs one clause and prevents a phantom success later | The underlying rule is one sentence: **every writer of a guarded row must advance its version, whether or not it checks it.** Checking is optional per writer; advancing is not, because other people's checks depend on it. ## The deliberate increment There is a second, constructive use of the same lever. Sometimes the rule being protected does not live on the row being written. An order's total must not exceed a limit, but the write inserts a line; a folder's item count must stay bounded, but the write adds an item. Two such writes can each be valid against the parent they read and invalid together, and neither one touches the parent row, so no guard fires. The fix is to bring the parent into the write on purpose: read it, and force its version forward as part of the same transaction. Now two concurrent child writes both try to advance the same parent version, one of them finds it moved, and the invariant is protected without locking anything for the duration of a user's editing session. Some layers expose this as a request made when loading the parent; where they do not, changing any field on the parent has the same effect. The cost is deliberate contention: every child write now serialises against every other child write under that parent, which is the point, but also the reason not to apply it to parents whose children are genuinely independent. ## Symptoms in the wild - Edits that "come back" after a batch job runs - a stale holder wrote over it, passing the guard. - Conflict rates that spike right after an import, because the import advanced versions on rows people had open. - An invariant that is violated only under concurrency and cannot be reproduced by hand - usually a rule on a parent that no write ever touches. ## What not to conclude None of this means set-based writes are wrong; they are the right tool for changing many rows and reading none. It means they are a **second write path** with its own contract with the version column. Treat the increment as part of that contract, keep the two paths from overlapping inside one unit of work, and reserve the deliberate parent increment for invariants that genuinely span rows.