platform: interrupted install ignores a replacement runtime token and never updates deployed Workers
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- typescript
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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:
- The CLI keeps using the runtime token saved in the checkpoint and ignores the replacement in the environment.
- Even when the replacement is used, Workers that are already deployed keep their old
CF_API_TOKENsecret.
Where this happens (v1.5.0)
The saved token wins once the install is past the draft stage.
-
A resumed install counts as a "setup draft" only while it has no resources and no API URL: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-setup-draft.ts#L32-L40
-
For any later stage,
configured()prefers the checkpoint value over the environment variable: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-lifecycle.ts#L915 and https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-lifecycle.ts#L936-L939 -
The recovery for a rejected token (clear the saved token, then prompt for a replacement) only runs for a draft on a TTY: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-lifecycle.ts#L969-L1043
So a non-draft resume with a revoked saved token fails verification every time, and an environment replacement does not help.
Existing Workers never receive the new token.
- The install path builds its secrets without
updateExistingWorkers, soworkerSecretUpdatesis empty: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-lifecycle.ts#L1154-L1169 and https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-installer-secrets.ts#L193-L196 - A Worker whose plan action is not
createcounts as existing: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-install-workers.ts#L274-L281 - An existing Worker only receives secrets listed in
workerSecretUpdates: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/platform-installer-secrets.ts#L518-L553 - Everything else is uploaded as
inheritfrom the active version: https://github.com/voidzero-dev/void/blob/afeeff6a4d72682f6cfb6c947e9a2c29393c00a6/packages/void/src/cli/cf-version-api.ts#L137-L142
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
- Run
void platform install --workers-devand interrupt it after the API and proxy Workers are deployed but before it finishes, for example by stopping at a later failing step. - Revoke the runtime token in Cloudflare and create a replacement with the same permissions.
- Run
VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN=<replacement> void platform install --resume --name <id>. - Runtime token verification uses the saved (revoked) token and fails.
- 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
- On a non-draft resume, should an explicit
VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKENwin over the saved checkpoint value, as it already does for drafts? - When the resolved runtime token differs from the saved one, should resume push
CF_API_TOKENto the existing API and proxy Workers through the existingworkerSecretUpdatesand 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.
- Langage dominant
- TypeScript
- Étoiles
- 627
- Forks
- 66
- Merge moyen
- 14 h 56 min
- PR mergées (30 j)
- 170
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de voidzero-dev/void
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
voidzero-dev/void#677 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 3/5 1-2 jours Accessibilité débutants 52/100
voidzero-dev/void#680 ·
Les mainteneurs répondent en général sous 1 jour
-
`withValidator({ body })` rejects the multipart bodies that `useForm` and `action()` send for filesOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
voidzero-dev/void#679 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
voidzero-dev/void#676 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 18/100
voidzero-dev/void#667 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de voidzero-dev/void
Issues similaires
-
needs-area
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Azure/typespec-azure#5936 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 Une demi-journée Accessibilité débutants 72/100
vercel-labs/scriptc#2910 ·
Les mainteneurs répondent en général sous 1 jour
-
automation missing-model model-sync provider:fireworks-ai
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
anomalyco/models.dev#12458 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour