Repository navigation
CoderMCPServer: test the opt-in disable after a crash between marker write and PATCH, and document the window (before M9) #365
Description
Summary
Two follow-ups from the final assessment of #360 (M6e). Gate: before M9 (CoderMCPServer activation).
- Regression test for the crash window. The controller writes
appliedGenerationbefore the opt-in disable PATCH. Add a test for: marker written, PATCH not sent (process stops), opt-in still withdrawn. The next reconcile must still send theenabled: falsePATCH. The code does this today (the "done" decision comes from Coder's answer, not fromappliedGeneration), but no test covers this exact path. - Document the known limit (review comment 4271304269 on 🤖 feat: disable the CoderMCPServer config when the control plane withdraws its opt-in #360). If the process stops after the marker write and before the disable PATCH, and the opt-in or consent comes back before the next reconcile, the sync applies the current spec without a spec edit. Coder never disabled the config in that window, and no credential goes to an origin without consent. Add one sentence near
sendMCPServerDisableand in the M9 how-to.
Refs #155
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: medium
Activity
ThomasK33 commentedon Oct 14, 2026
One more case for this issue, from the final assessment of #363: the controller writes the disable marker, the PATCH fails without committing, and consent comes back while the config is still enabled. The pending generation then counts as applied. Confirm with a test whether the drift sync re-applies the spec edit made before the disable, or whether it is lost until another edit, and document the result next to the other limit.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:medium