🤖 fix: make aggregated quickstart creation and repeated apply converge

[ThomasK33]

Observed behavior

Part of #89's installer testing. The proposed quickstart bundle cannot be applied successfully or converge on repeated apply, even with a PostgreSQL-backed control plane reporting phase=Ready and operatorAccessReady=true.

Observed in isolated KIND by the installer worker on private candidate 5222d49147ba3682c53821ccc13542f0462c5f9a (PR89 integrated with main cd378781). This candidate is not pushed. Final public source/evidence links will follow when available.

1. Apply dist/quickstart-installer.yaml. The template requested as default.quickstart-template is returned as coder.quickstart-template. Workspace creation fails with The provided template version is running. Wait for it to complete importing!.
2. Apply the same bundle again. The template patch fails with precondition failed; the workspace is created under canonical name coder.coder-k8s-operator.quickstart-workspace rather than the requested aliases.
3. Further applies still fail: template precondition failure and workspace AlreadyExists. Existing resources do not make the command succeed.

The worker traced canonical naming to template/workspace conversion using organization/owner names. Template Create does not wait for the import build, whereas Update does. These are diagnosis leads for a focused regression investigation, not a claim that adding waits alone is the right fix.

Scope and disposition

The API behavior is inherited. PR89 introduced the unsupported tutorial promise. PR89 is being reduced to supported minimal installation; the generated quickstart example will be clearly marked unsupported. This issue tracks restoration of a supported quickstart path, not unrelated database configuration work in #97.

Acceptance and follow-up

• Add failing regression tests for alias requests versus canonical responses and repeat-apply behavior for templates and workspaces.
• Define and test the template-import readiness contract, including workspace creation before and after import completes.
• Verify the supported documented flow in an isolated cluster: initial creation, resource readiness, repeated apply, and cleanup. All documented successful commands must exit zero.
• Restore the runnable quickstart guidance only after that coverage and hands-on validation pass.

Owner: maintainer desk. Follow-up trigger: the next aggregated-API correctness increment, before quickstart is advertised as supported. No API fix is included in PR89's current scope.

Evidence: attempt 6 retained native exits (quickstart step exit 1), sanitized logs, screenshots, recording, and cleanup receipt. Public attachments remain pending; this issue does not claim media is already attached.

---

Generated with xum • Model: coder:bedrock-mantle-us-west-2/openai.gpt-6-astra • Thinking: xhigh

[ThomasK33]

Next correctness increment

A bounded, private diagnosis is now running against main cfdd89749111d542e3fc7632ea1b8fa1fae1b49b.

1. Reproduce template and workspace alias identity failures through the storage/API paths, including GET and repeated apply/update.
2. Test template-import readiness separately. Do not assume waits or retries fix the naming problem.
3. Select the smallest independently useful fix from executable regression evidence. No production fix or PR has been published for this issue yet.

The first target is identity and repeated-apply correctness if it can stand alone. Import readiness and the complete supported quickstart remain outstanding until separately verified. This work does not change PR #89's private minimal-installer scope or review ledger.

Owner: maintainer desk. The diagnosis is timeboxed to 45 minutes and ends with a concrete implementation brief or a specific blocker. Acceptance for a delivered fix includes regression tests, required repository checks, and isolated cluster evidence with screenshots and video. This issue remains open until the full acceptance above is met.

---

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

[ThomasK33]

Updated triage on current main (0a181457)

1. Aliases: requests for templates or workspaces under a non-canonical organization or owner name (for example default.<template> or a me owner) now fail with 400 before any mutation (🤖 fix: enforce canonical organization and owner names #106, 🤖 fix: enforce canonical template and workspace leaf names #111). The "created under a different name" symptom is gone, but supported manifests must use canonical names.
2. Template import readiness: still present. For templates created with spec.files, Create returns before the Coder import finishes, so a workspace created right afterwards fails with 400 ("template version is running"). Template Update already waits for the import.
3. Repeated apply: not yet proven. The workspace AlreadyExists came from the alias path, which now fails early. The cause of the template precondition failed has not been established.

Plan (one PR):

• Template Create with spec.files waits for the import before creating the template. A failed or timed-out import creates no template; the uploaded file and version may remain in Coder, and a retry can create another version.
• The maintained E2E creates the template after its setup steps and immediately asserts that the import has succeeded, before creating a workspace.
• The E2E re-applies identical canonical template and workspace manifests with kubectl apply and requires success with no new versions or builds. If that does not converge, the failure will be captured and split into its own issue rather than worked around.

Out of scope: quickstart docs and PR #89, template resourceVersion changes, status conditions.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: xhigh

[ThomasK33]

Delivered by #116, landed as c58c85148be8623a98940f33219e187dea72fcd3 through the merge queue. Its tree is identical to the reviewed and tested head f5bf93b7.

Outcome for each part of this issue:

1. Alias names: already resolved on main by 🤖 fix: enforce canonical organization and owner names #106 and 🤖 fix: enforce canonical template and workspace leaf names #111. Non-canonical organization or owner names are rejected with 400 before any mutation, instead of being created under a different name. Supported manifests use canonical names.
2. Template import readiness: fixed. A CoderTemplate created with spec.files is created only after Coder's import succeeds, so workspaces can use it immediately. A failed or timed-out import creates no template; the uploaded file and version remain in Coder, as documented.
3. Repeated apply: verified on a real backend. Re-applying identical canonical template and workspace manifests with kubectl apply succeeds and changes nothing.

Evidence:

• Unit tests: written first; they failed on the old code and pass with the fix. They cover the pending-import wait and six failure modes, none of which creates a template.
• End-to-end: the maintained Kind E2E passed 12 of 12 cases on the PR head (run 35845782860) and again on the landed commit (merge-group run 35848006748). In both runs the template import had already succeeded when checked right after kubectl apply. After re-applying both manifests there was still one template version and one workspace build, with no apply failure.
• Post-merge: main CI 35848571109 published ghcr.io/coder/coder-k8s:main from c58c8514. Docs 35848571038 deployed.
• Reviews: 3 of 6 assessments, all clean: Codex code review and security review on the head, and an independent final assessment.

Follow-ups:

• Imports that take longer than the request deadline (kube-apiserver defaults to 60 seconds for proxied requests) return a timeout and can leave extra versions on retry. This is tracked in 🤖 fix: handle template imports that outlast the request deadline #117.
• Restoring a supported quickstart path, and PR 🤖 feat: ship generated install bundle and CI freshness checks #89's installer, remain separate. The quickstart must use canonical names.
• The terminal replay of the CI log is retained, but not attached because GitHub attachment uploads are currently accepted but not served.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: xhigh