frontend-patterns/research/bench/sources/kubernetes-stale-writes.md
tegwick 96d11431dc Expand transactional editing evidence and compare authority cases
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-25 10:32:13 +02:00

29 lines
1.2 KiB
Markdown

---
source_id: SRC-0008
title: Kubernetes API Concepts
author: Kubernetes project
locator: https://kubernetes.io/docs/reference/using-api/api-concepts/
version: Living documentation accessed 2026-09-25; exact revision unknown
accessed: '2026-09-25'
evidence_kind: primary
excerpt_scope: Stale resource version rejection only
---
# Bounded stale-write packet
## Editorial context (not source text)
The section concerns updates to existing resources, including HTTP PUT with a
client-provided resourceVersion. Kubernetes is the single implementation examined.
## Original passage — Updates to existing resources, second paragraph
> In the event that the resource has changed (the `resourceVersion` the client provided is stale), the API server returns a `409 Conflict` error response.
## Research question (editorial)
What boundary between a client proposal and server acceptance does this establish?
Consider an editor retaining its draft after rejection. That UI is a hypothesis,
not observed implementation evidence. Do not generalize to unconditional PATCH,
deduplication, response loss or every server API. One implementation cannot establish
recurrence. Return no candidate if the excerpt is insufficient.