🤖 fix: make workspace resource versions reflect backend changes

[ThomasK33]

Problem

CoderWorkspace.metadata.resourceVersion is derived from Coder's Workspace.UpdatedAt in the converter. In an owned KIND deployment running Coder v2.37.2, workspace builds, rename, TTL changes, and autostart changes did not advance that timestamp. The exposed resourceVersion therefore did not identify those same-object changes.

This limits the value of resourceVersion-based change detection and DELETE preconditions. UID checks protect object identity, not changes to the same object. This behavior predates the DELETE-precondition work in #108; changing version derivation is a separate contract. The template case is different: a tested metadata update changed its exposed resourceVersion.

Evidence and limits

During #108's isolated HTTP dogfood, successful backend mutations retained the same workspace ID and updated_at value. A test requiring a new resourceVersion after a same-ID rename failed; that failed receipt is retained. A deliberately different resourceVersion produced HTTP 409 with the workspace intact, but that proves equality checking only, not detection of real workspace changes.

These are observations of the listed operations on v2.37.2. They do not establish that the timestamp never changes, that it is set only at creation, or that every Coder version behaves identically. No cross-tenant or production exploit is claimed.

Acceptance criteria

1. Establish which supported Coder fields identify changes to the workspace representation. Cover build state, rename, TTL, and autostart; do not assume a latest-build timestamp covers them all.
2. Define the resourceVersion contract and compatibility implications before implementation. Keep values opaque to clients. Do not claim that hashing fields creates a monotonically increasing version.
3. Add failing converter/storage tests for real representation changes, stable unchanged reads, and delete/recreate identity changes. Choose the smallest version scheme supported by the evidence; avoid a new persistence subsystem unless separately justified.
4. Verify real backend changes on the same workspace ID produce the expected versions through the aggregated API. Then prove an old-version DELETE returns 409 and leaves the current object intact. Exercise LIST, GET, updates, and watch behavior so version changes do not introduce regressions.
5. Preserve UID identity protection, namespace isolation, and the documented non-atomic backend-delete boundary. Run repository gates and retain exact-SHA recorded KIND evidence with owned-resource cleanup.

Ownership and sequencing

Owner: maintainer desk. Follow #108's DELETE-options enforcement and #107's canonical leaf-name fix. Resolve this issue before claiming workspace resourceVersion protects against updates to the same object. It does not expand either current fix into a new versioning design.

---

Generated with xum • Model: coder:openai/gpt-6-astra • Thinking: xhigh

[ThomasK33]

Diagnosis and implementation contract

The exact landed base 2fcd31d42a345a80841e2f5133ee8f796388da78 reproduces the bug in converter and storage tests with a fixed backend updated_at:

1. Build, build-status, rename, TTL and autostart changes keep the exposed version unchanged.
2. An UPDATE response can carry a different version from the next GET of the unchanged backend snapshot.
3. DELETE accepts the pre-update version after a build change. Existing package controls pass; the focused storage reproduction repeats with the same failures. A first storage attempt failed fixture setup and is retained separately, not counted as product evidence.

The bounded fix will use a full SHA-256 fingerprint of the workspace representation emitted by the converter, with resourceVersion unset while hashing. This includes exposed lastUsedAt and autoShutdown: activity that changes these fields can legitimately invalidate a cached token. Templates are unchanged.

The token remains opaque. It is not monotonic, can repeat if the entire representation returns to its prior value, and is not an atomic backend compare-and-swap. Existing cached timestamp tokens require a fresh read after upgrade. Watch remains local write notification only, without historical replay or out-of-band Coder events. Response/GET equality is required only when the backend projection is unchanged between them.

Next: the minimal converter/storage/docs change, regression gates, then exact-commit recorded KIND validation of real backend changes and stale-version rejection. No persistence subsystem or watch redesign is included.

---

Generated with xum • Model: coder:openai/gpt-6-astra • Thinking: xhigh

[ThomasK33]

Runtime validation checkpoint

The implementation passed all 12 local gates on candidate d47370607325aec744667d5a17f9e89f3ca375f3. Runtime acceptance is not complete.

1. The fourth recorded KIND run demonstrated same-UID/new-token behavior for backend build, TTL, and autostart changes. GET/LIST projection checks passed. Each stale DELETE returned 409 with the object/build intact; a genuine pre-build stale UPDATE also returned 409 without another build. Coder's updated_at was unchanged across these operations.
2. The run then failed before the API-driven UPDATE/watch scenario. A watch without RV was defaulted into unsupported initial-event options and returned 400. The relevant watch/defaulting implementation is unchanged from the base. The missed defaulting step and the compatibility/docs work are tracked in 🤖 fix: clarify event-only watch options after Kubernetes defaulting #112.
3. API-driven UPDATE with the matching local MODIFIED event, rename, and live-delete/recreate checks remain unverified in this runtime packet. The first three failed runs and this fourth failure are preserved; none is relabeled green.
4. Full-suite relaunches for this tranche are stopped. Next is a separately gated, read-only watch-option diagnostic on the exact retained fixture. Only if it confirms the explanation will a separately recorded supplement exercise the missing cases. No watch redesign is part of this fix.

Local clients from the failed run have stopped. Its exact owned cluster/image remain retained for that bounded diagnosis; resource cleanup is still outstanding. No PR has been opened, and publication remains blocked on complete acceptance evidence and honest documentation.

---

Generated with xum • Model: coder:openai/gpt-6-astra • Thinking: xhigh

[ThomasK33]

Validation blocked; test environment cleaned up

The candidate remains unpublished. No PR is open, and this issue remains open.

1. Final local commit 67067993f98e972ab3dc78f56159d8277dbd6ef7 passed all 12 static gates: focused regressions, test, build, vendor consistency, lint, docs build, spelling, Markdown lint, reference-doc checks, actionlint, govulncheck, and Trivy filesystem scan. It differs from d4737060 only in watch documentation; every other tracked entry is identical. The earlier core runtime evidence still comes from d4737060, not a final-commit execution.
2. The watch diagnostic established a working request with the current opaque resourceVersion and neither sendInitialEvents nor resourceVersionMatch. The docs now state the observed defaulting/rejection limits. Broader watch compatibility remains tracked in 🤖 fix: clarify event-only watch options after Kubernetes defaulting #112.
3. The final-commit supplement built and deployed the artifact, then failed its provenance assertion because it observed two Running pods. The historical claim that the old pod was terminating is not proven by a saved deletionTimestamp. A later read-only audit found one ready final-image pod and its matching serving endpoint; that does not turn the failed run into a pass.
4. No final-artifact UPDATE/local MODIFIED, rename, or live DELETE/recreate/prior-UID cases ran. The proposed last retry was canceled: its preflight had command failures followed by a retry despite the stop-on-failure boundary. It never launched. All failed runs remain labeled FAIL; no more functional runs are authorized in this tranche.
5. Identity-gated cleanup completed at 23:06Z on September 22. Successful enumerations confirmed removal of the owned KIND cluster/container and both owned image IDs/tags. Recorded local clients, three kubeconfig copies, and three temporary directories are absent. Logs, raw recordings, and failure manifests remain intact. Cleanup checks were corrected before execution to reject an empty process-root list and to require successful image enumeration rather than treating any inspect error as absence.

Disposition and unblock condition: the read-only recovery memo did not establish a credible smaller route; its proposed full-suite rerun is rejected. Runtime retries remain canceled. The maintainer desk owns the prerequisites for considering a future plan: a materially smaller missing-case path, preferably in an existing maintained harness, and separately authorized offline tests of request construction, stop behavior, provenance, and cleanup. A favorable memo, offline passes, cleanup, or a new packet does not authorize a live run or replace the missing final-artifact acceptance. The desk will make an explicit decision only when materially new evidence exists; meanwhile it will advance independent repository-health work.

Failed-run evidence

The screenshot shows the native provenance failure. The video is a post-hoc idle-trimmed export of the live terminal capture (10.8 seconds), not a new run or a passing demonstration.

e2e-idle-trimmed-posthoc.webm

---

Generated with xum • Model: coder:openai/gpt-6-astra • Thinking: xhigh