Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A remote patch should be rejected, not applied blindly, when the target has changed since the patch was built and the changed region overlaps the patch. The safe pattern is to bind each patch to the version it was created from, check that version atomically when the patch arrives, and apply the whole change set or none of it. Only changes that do not overlap can be combined automatically, and only when your system can compute overlap reliably. When overlap cannot be ruled out, the server should keep both sides intact and return the current state or a conflict description so the client can reconcile.
Why a patch needs a known base
A patch is a set of instructions that only makes sense relative to some earlier state. “Replace the third line” or “set status to closed” assumes the reader of the instruction saw the same document or record the writer did. If someone edited the target while the patch was in transit or queued, those instructions can land on the wrong content. The result is a lost update: the stale patch silently overwrites a newer local edit, and nobody is told.
The fix starts before the patch is sent. The client reads the target, keeps the version identifier or entity tag that came with that read, and builds the patch against that base. RFC 5789, the IETF standard for the HTTP PATCH method, supports conditional requests for patch formats that depend on a known base point. In practice that means a strong ETag sent in an If-Match header.
Step one: attach a precondition to the patch
The precondition is the mechanism that lets the server detect a stale patch. An illustrative exchange looks like this:
#1 Best Overall
PATCH /documents/42 HTTP/1.1
Host: api.example.com
If-Match: "v7"
[patch operations built against version v7]If the current representation is still "v7", the server evaluates the patch. If it has moved on to "v8", the precondition fails and the server should not touch the resource. The response for a failed explicit precondition is 412 Precondition Failed, which RFC 5789 identifies as the most helpful status in that case. The response body or headers should carry enough of the current state, or a conflict description, for the client to recover. The exact shape is part of your API contract.
Step two: apply the change set all or nothing
Checking the precondition is not enough on its own. The server must also make sure a multi-operation patch cannot half-apply. RFC 5789, Section 2, states: “The server MUST apply the entire set of changes atomically and never provide (e.g., in response to a GET during this operation) a partially modified representation.” RFC 5789
Atomicity matters most when the server runs several checks in sequence. If operation three of five fails after operations one and two were written, the stored record is neither the old version nor the intended new one. A transaction, a compare-and-swap on the version field, or a single write that includes the version check all satisfy the rule. The version check and the write must be part of the same atomic step, or a second writer can slip in between them.
Free tools Windows power users keep installed
One-click scans. No signup required.
A version mismatch is a signal, not proof of overlap
A version change tells you that something happened. It does not tell you what happened. Two common systems show the two ends of the spectrum:
- Kubernetes rejects an update whose
resourceVersionis stale with409 Conflict. The API does not try to work out whether the two edits touched the same fields. The client must re-read the object, reapply its change, and retry. See Kubernetes API Concepts. - Git merges changes from two branches and incorporates edits to different parts of a file without asking anyone. Only the regions that both sides changed become conflicts. See the git-merge documentation.
Do not treat every version increment as a collision. Do not treat two edits in different places as automatically safe either. The right response depends on your data model and on whether your system can determine overlap accurately.
What counts as overlap
Overlap is an application decision. The sources describe patterns and examples, not a universal algorithm, so you need to define the rule for your own resources.
Same region edited on both sides
The simplest case is that both the remote patch and a local edit change the same text, field, or array element. GitHub lists competing changes to the same line as a common cause of merge conflicts, and that same logic applies to structured records. If both sides change one field, reject the patch unless the new value is identical to the current one.
Edit versus delete
One side modifies an item while the other removes it. GitHub also identifies this situation as a common conflict. A patch that adds a comment to a record deleted in the meantime should fail with a conflict, not recreate a partial object. Confirm how your API handles operations that reference missing items, and report a conflict rather than inventing a result.
Textually separate but semantically linked
Changes to different lines or different fields can still conflict. Structured data often has dependencies across fields, such as a total that depends on line items, a status that depends on a due date, or a permission that depends on a role. Two patches that touch separate fields can still produce an invalid record. Only combine them when your rules confirm that the combined result satisfies every validation constraint.
Choosing a strategy
Two broad strategies appear in the sources. Most systems use one, or a hybrid of both.
| Comparison axis | Strict optimistic concurrency | Three-way or operation-aware merge |
|---|---|---|
| Behavior on a stale base | Reject the mutation; client reloads and retries | Compare base, current, and incoming versions; apply non-overlapping changes; surface overlaps |
| Overlap detection | Not needed; any stale version is treated as a conflict | Required; depends on semantic rules for the resource |
| Lost-update protection | Strong, because stale writes are never applied | Strong only if overlap rules are correct; errors here can silently drop or corrupt data |
| Client burden | Re-read, reapply, and retry on each conflict | Fewer retries for disjoint edits; reviewers must handle real overlaps |
| Server complexity | Version check and atomic write | Also needs merge logic and a conflict representation |
| Examples in the sources | Kubernetes and AWS AppSync | Git and VS Code conflict review |
Kubernetes and AWS AppSync both document version-based stale-write rejection. AppSync’s optimistic concurrency behavior provides the latest server item to the client so that it can retry. Git and VS Code show what a merge looks like when the system can separate non-overlapping changes from real conflicts. These are different APIs with different semantics, so treat them as patterns, not as drop-in implementations.
Recommended Free Tools
Choosing the status code
The status code should describe what the server actually detected:
- 412 Precondition Failed when the request included an explicit precondition, such as
If-Match, and that precondition no longer holds. - 409 Conflict when the server detects a possibly conflicting modification and no precondition was supplied. RFC 5789 allows this use.
- 409 Conflict is also the status Kubernetes returns for stale
resourceVersionupdates. Match the response to the request and to your API’s documented contract, and keep the meaning consistent across endpoints.
A working flow for the server and client
- Read the target and keep its version. On the client, store the ETag or
resourceVersionthat came with the read. - Build the patch against that base. Record which fields or ranges each operation touches so the server can check overlap later.
- Verify the precondition atomically. On the server, compare the supplied version with the stored version inside the same write transaction.
- If the check fails, compare regions only when merge semantics are trustworthy. Load the edits made since the base and compare their affected fields or operations with the patch.
- Apply disjoint operations only under written rules. Define exactly which combinations are safe, then verify the result against your validation rules before committing.
- Reject overlaps and return the latest state or conflict details. Do not write a partial result. If overlap cannot be computed safely, reject the stale operation and require a refresh instead of guessing.
- Retry with a fresh precondition. The client re-reads, incorporates the intervening change, and submits again with the new version.
Step four is optional. Many systems should stop at step three and use strict rejection, especially when they cannot model the resource’s dependencies precisely.
When a person has to resolve the conflict
Some conflicts need human judgment. GitHub’s merge conflict documentation describes the need to resolve conflicts before a merge can complete. VS Code’s merge conflict view shows the competing versions and offers actions to accept one side or the other. Those tools help a reviewer see both versions, but accepting a side does not guarantee the combined result is valid for your data model. After a manual resolution, run the same validation the server would run on a normal write.
Keep the rejected patch available to the user until the reconciled version is saved. Discarding it at the moment of rejection makes the local edit impossible to recover.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Common mistakes
- Treating a missing precondition as permission to overwrite. Requests without a version check should be rejected or flagged, not applied unconditionally, when the resource can change concurrently.
- Checking the version outside the write. A check followed by a separate write leaves a gap that a second writer can use.
- Merging by line or key alone. Textually separate edits can still break semantic rules across fields.
- Returning a bare error. A rejection without the current state forces the client to guess what changed.
”
The Bottom Line
“”
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
