# Fix kubectl "the object has been modified" conflicts

## TL;DR
Something changed the object between your read and your write. Re-fetch the latest copy and apply your change on top of it; for scripts, wrap apply in a retry loop or switch to server-side apply, which merges instead of replacing. The API rejects stale writes on purpose so nobody silently clobbers someone else's change.

```text
"the object has been modified; please apply your changes to the latest version" kubectl concurrency fix
```

## Steps

1. **Re-read the object.** Run `kubectl get [kind] [name] -o yaml` and note you now have the latest resourceVersion.
   Expected: you are looking at the current state, including whoever else's change.

2. **Re-apply your change on the fresh copy.** `kubectl edit` does this re-fetch automatically when you save and retry.
   Expected: the write succeeds because your base is current.

3. **If a controller keeps fighting you, edit the source of truth.** Do not hand-edit a ReplicaSet that a Deployment manages, or a pod that a controller owns.
   Expected: no more conflicts, because you stopped editing the thing that gets reconciled away.

4. **For automation, retry or go server-side.** Wrap `kubectl apply` in a retry loop, or use `kubectl apply --server-side`, which merges fields instead of replacing the whole object.
   Expected: concurrent writers stop clobbering each other.

5. **If two humans edit the same object, coordinate.** One writer at a time.
   Expected: obvious, and it works.

## Use this when
- kubectl edit, apply, or replace fails with the object-modified message
- A controller (HPA, deployment controller, operator) reverts your manual edits
- CI jobs race each other updating the same resource

## Not for this skill when
- The error is Forbidden or Unauthorized (that is RBAC)
- An admission webhook rejects the change (that is policy, not concurrency)
- The schema is invalid (that is a validation error)

## Variant phrasings
- kubectl conflict error
- resourceVersion conflict kubernetes
- optimistic concurrency kubernetes
- operation cannot be fulfilled on resource

## Why it happens
The API server uses resourceVersion for optimistic concurrency: every write carries the version the writer based it on. If the stored version moved on, the write is rejected rather than silently overwriting the other change. It is a safety feature, not a bug.

## Edge cases
- `kubectl replace --force` deletes and recreates the object. Avoid it for anything stateful.
- Server-side apply tracks field ownership. Two managers fighting over the same field still conflict, just with a clearer message.
- Some operators revert manual edits within seconds. That is the operator working as designed; change the operator's input, not its output.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst__jbRjgSO2czqPfBA-Rc2Rg