platform: interrupted install ignores a replacement runtime token and never updates deployed Workers

Chiusa
  • Qualcosa non va?
#666 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Brooooooklyn ci sta già lavorando.

Dal 3/11/2026.

  • #682 di @Brooooooklyn — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
cli, cloud

Direzione di ricerca

Start in packages/void/src/cli/platform-lifecycle.ts, where configured() prefers the checkpoint token over the environment variable and the rejected-token recovery runs only for drafts on a TTY. Then read platform-installer-secrets.ts and platform-install-workers.ts to see how workerSecretUpdates is built and why existing Workers receive no CF_API_TOKEN update. Done means a resumed install uses an explicit replacement token and pushes it to existing API and proxy Workers, with tests covering both paths; the maintainer has not yet chosen the behaviour.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Suppose void platform install stops after it has created resources or deployed the API and proxy Workers, and the operator then has to replace the runtime token, for example because the original was revoked or rotated. Resuming with VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN=<replacement> void platform install --resume --name <id> has two problems:

  1. The CLI keeps using the runtime token saved in the checkpoint and ignores the replacement in the environment.
  2. Even when the replacement is used, Workers that are already deployed keep their old CF_API_TOKEN secret.
Where this happens (v1.5.0)

The saved token wins once the install is past the draft stage.

Existing Workers never receive the new token.

So if the old token still verifies, the API and proxy Workers already deployed in the interrupted run keep running with it. Revoking it later breaks app deploys from the platform. Today, only the installed-platform maintenance path passes updateExistingWorkers: true: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-management.ts#L575-L585

#569 made interrupted credential updates resumable on that maintenance path. The install-resume path does not appear to feed a replacement runtime token into the same mechanism.

Synthetic repro
  1. Run void platform install --workers-dev and interrupt it after the API and proxy Workers are deployed but before it finishes, for example by stopping at a later failing step.
  2. Revoke the runtime token in Cloudflare and create a replacement with the same permissions.
  3. Run VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN=<replacement> void platform install --resume --name <id>.
  4. Runtime token verification uses the saved (revoked) token and fails.
  5. Variant: if step 2 does not revoke the old token, the resume completes, but the API and proxy Workers still hold the old token.
Questions
  1. On a non-draft resume, should an explicit VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN win over the saved checkpoint value, as it already does for drafts?
  2. When the resolved runtime token differs from the saved one, should resume push CF_API_TOKEN to the existing API and proxy Workers through the existing workerSecretUpdates and intent mechanism? Or would you prefer that resume refuses and points to a separate command?

I'm happy to open a PR for whichever behaviour you prefer.

Prepared with Claude Code on behalf of @iPLAYCAFE-dev; reviewed by the maintainer of this account.

Lingua principale
TypeScript
Stelle
627
Fork
66
Merge medio
14h 38m
PR unite (30g)
179

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/void

Tutte le issue di voidzero-dev/void

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.