platform: interrupted install ignores a replacement runtime token and never updates deployed Workers
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
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.
Written by the indexing model from the issue text.
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.
- Dominant language
- TypeScript
- Stars
- 627
- Forks
- 66
- Avg merge
- 14h 38m
- Merged PRs (30d)
- 179
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/void
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
voidzero-dev/void#677 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
voidzero-dev/void#689 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
voidzero-dev/void#686 ·
Maintainers usually reply within 1 day
-
`VoidActionError.message` ignores the server's message, though the docs show it to usersPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 3/5 1-2 days Newbie friendliness 52/100
voidzero-dev/void#680 ·
Maintainers usually reply within 1 day
-
`withValidator({ body })` rejects the multipart bodies that `useForm` and `action()` send for filesOpen
Difficulty 4/5 3-5 days Newbie friendliness 35/100
voidzero-dev/void#679 ·
Maintainers usually reply within 1 day
All issues in voidzero-dev/void
Similar issues
-
test: claim-conflict drop leaves both facts active and is never re-proposed (untested review cell)Open
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
[Feature]: Usage page should show API-equivalent cost and say when a connected plan shows info onlyOpenenhancement from-x
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
nightly-labs/openbot#4867 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
egonSchiele/agency-lang#1377 ·
Maintainers usually reply within 1 day
-
normalizePath removes the Windows device namespace prefixPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
caprover/caprover-frontend#273 ·
Maintainers usually reply within 1 day