Conditional Writes and Lost-Update Prevention

Working case

Reviewers 29 and 31 both open case 47 at version 62. Reviewer 29 adds a safety note and saves version 63. Reviewer 31 still has version 62 and changes the status to resolved. Without a precondition, the second save can replace the note or overwrite a decision made from stale context. The server rejects reviewer 31's old validator. The interface fetches the current case, shows the difference, and asks for an informed merge or new action. It must preserve reviewer 31's unsaved text while doing so.

Implementation boundary

function conditionalCaseUpdate(ifMatch, currentVersion) {
  if (ifMatch === null) return { status: 428, nextVersion: currentVersion };
  const expectedTag = `"case-47-v${currentVersion}"`;
  if (ifMatch !== expectedTag) return { status: 412, nextVersion: currentVersion };
  return { status: 200, nextVersion: currentVersion + 1 };
}
console.log(conditionalCaseUpdate(`"case-47-v62"`, 63).status);
// Output: 412

The function illustrates response decisions, not a transaction. In production, compare the current version and apply the mutation in one atomic database operation, then return the new strong validator with the representation. If a case has multiple variants, be precise about which selected representation the validator covers. A weak validator is not suitable for a lost-update guard. Authorization and field validation still run; a matching validator does not grant permission or make the submitted data valid. For a failed condition, return enough safe current-state information for recovery without leaking another user's private fields.

Cost and boundaries

A version check is O(1) for one record, and an atomic conditional update can use the record key and version in a single indexed write. The greater cost is the conflict workflow: users may need to review differences and reapply a change. A validator stored per resource adds little data, but every relevant mutation must advance it consistently. High-write records can see frequent conflicts. Do not hide that by retrying a conflicting write automatically; an automatic retry can reintroduce the overwrite the precondition was meant to prevent.

Failure trace

A handler reads version 62, checks If-Match, and then writes without including the version in the database update predicate. Another request commits version 63 between the check and write, so both saves succeed. The API reports a new validator even though one edit was lost. Reproduce with two concurrent requests and move the comparison into the atomic write. Separately test an omitted header and a stale one, since they are different client errors. Preserve the rejected user's draft during recovery.

Verification

Two concurrent edits from one version cannot both overwrite the same record silently.
Missing and stale preconditions produce distinct recoverable responses.
Conflict recovery preserves the user's draft and rechecks authorization.

Practice drill

Open case 47 in two sessions at version 62. Save a note in one and a status change in the other. The second request must not silently win. Inspect the HTTP status, returned validator, and stored record after both orders. Remove If-Match and check the required-precondition response. Then deliberately race the server between validation and persistence; if both writes succeed, the database condition is missing. Repeat with a user who lacks permission to ensure the validator is not treated as authority.