fastly-compute-publish-ignores-draft-versions

fastly compute publish ignores non-active draft versions

Problem

Fastly service versions are immutable. To change a service you clone the active version, edit the clone (a draft), then activate the clone. Multiple tools create drafts:

• fastly service backend create --autoclone — creates a draft off the active version and adds the backend
• fastly service domain create --autoclone — same, for domains
• Dashboard UI "Clone" button
• fastly compute publish — also creates a draft, uploads WASM, activates

If you mix these tools on the same service you get a surprising footgun: each tool clones from the currently-active version, independently, and each activates its own clone. Draft versions that were never activated are abandoned. Their edits are invisible to whatever the next tool clones from.

Example sequence that bites:

t0  Active = v250
t1  $ fastly service backend create --version latest --autoclone \
       --name cloud_run_transcoder --address ...
    → creates v251 (clone of v250) + adds backend
    → v251 is DRAFT, not active
    → "latest" in this context means "highest version number" (v251), not "active version"

t2  $ fastly compute publish --comment "ship fix"
    → creates v252 (clone of v250, NOT v251) + new WASM
    → stages and activates v253 (clone of v252) + activates
    → v251's backend change was never carried forward
    → active = v253, which does NOT contain cloud_run_transcoder

t3  Compute code at v253 calls send_async("cloud_run_transcoder")
    → backend name does not exist on v253
    → silent failure, fire-and-forget hides it

The naming is misleading: --version latest does not mean "the latest active version," it means "the highest-numbered version," which can be a draft nobody activated. And fastly compute publish never looks at your draft — it clones from whatever is currently active. So your backend change is orphaned in an unreachable draft version, and the active version has the new code but the old backend list.