🐛 BUG: `deployments list` shows 🟩 Active when it's not

[mbforbes]

Which Cloudflare product(s) does this pertain to?

Wrangler core

What version(s) of the tool(s) are you using?

3.15.0

What version of Node are you using?

20.9.0

What operating system are you using?

Mac

Describe the Bug

My bug involves trying to take down a worker and then bring it back up.

My understanding is that to take down a worker, I must delete it (wrangler delete). So, imagine I want to take down a worker, then bring it back up. The worker depends on secrets, which wrangler delete also removes. So I add the secrets back first. Steps shown next.

Reproduction

wrangler delete
# I tried uploading twice, but it actually succeeds on the first try!
wrangler secret:bulk secrets.json # ✘ [ERROR] 🚨 1 secrets failed to upload
yarn wrangler secret list # shows the secrets actually there
wrangler secret:bulk secrets.json # ✨ 1 secrets successfully uploaded
wrangler deployments list

The output of the final wrangler deployments list shows:

Deployment ID: (redacted)
Created on:    2023-11-16T20:05:07.411569Z
Author:        (redacted)
Source:        Upload from Wrangler 🤠

Deployment ID: (redacted)
Created on:    2023-11-16T20:05:08.648391Z
Author:        (redacted)
Source:        Secret Change from Wrangler 🤠

Deployment ID: (redacted)
Created on:    2023-11-16T20:05:30.410174Z
Author:        (redacted)
Source:        Secret Change from Wrangler 🤠
🟩 Active

Trying with multiple (n) secrets, I see that I get n Upload from Wrangler 🤠s followed by n Secret Change from Wrangler 🤠s.

However, when I visit my deployment (at https://[app].[uname].workers.dev/), I get the "There is nothing here yet" page.

There are several surprising things here, so let me try to summarize with a table:

Step	Expected	Actual
Take down a deployment without deleting the deployment history	wrangler undeploy or wrangler down or wrangler unpublish	(none)
If wrangler secrets:bulk [file] shows ✘ [ERROR] 🚨 N secrets failed to upload, have the secrets actually been uploaded?	no	yes
Does wrangler secrets:bulk [file] cause n Upload from Wrangler 🤠s for n secrets?	no	yes
Does wrangler secrets:bulk [file] show no error message on the first try with no deployment?	yes	no
if wrangler deployments list shows 🟩 Active, is the deployment active?	yes	no

My apologies if I missed a cleaner way to un-deploy a worker! If it's easier that I file a separate issue for each row of the table, please let me know and I'm happy to do so.

(edits: accidentally submitted too early)

[CarmenPopoviciu]

hi @mbforbes,

When running wrangler secrets or wrangler secrets:bulk you'd ideally want to have deployed your Worker beforehand. If that is not the case, and the Worker script does not exist, both secrets and secrets:bulk will deploy a no-op Worker instead, which would explain the "There is nothing here yet" message. So basically, what you'd want to run in your case is:

wrangler delete
wrangler deploy
wrangler secret:bulk secrets.json

I am curious about your use case though, and would like understand more about the reason behind deleting the Worker. Would you mind elaborating on that a little 🙏 ?

[mbforbes]

Hey Carmen, thanks for the reply, let me try to remember since it's been a long time since I tried this!

Why delete the worker? I think there were two broad categories:

1. During development. Lots of experimentation with code, libraries, networking, etc. End up making test workers to try to get parts of the system working. Don't want to have many versions of half-working overlapping prototypes all live running — cognitive overhead.

2. During production. Being able to control whether a service (provided by a worker) is live. This is super common for me when building other cloud computing platforms — they have a notion of "pausing" or "un-deploying" a particular service without removing its identity and history. For example, testing combining two services into one, routing around a service, taking it down temporarily if it's causing capacity issues or bugs.

Re: secrets depending on having a live worker, otherwise deploying a no-op Worker, this is very helpful to know. My mental model of secrets was that they were just state, like environment variables, and didn't need a live runtime attached. I also wanted to get secrets (data) set up first so my run time could use it when it was deployed. So it was surprising to have the behavior I saw.

I hope this helps. Sorry if anything is vague, it's been a minute since I tried using them!

[petebacondarwin]

1. During development there should be no need to upload the secrets before deploying the worker. Just do them in the other order before testing the Worker.

[penalosa]

My mental model of secrets was that they were just state, like environment variables, and didn't need a live runtime attached

Worth noting that environment variables also work this way—they need a deployed worker to attach to.

Being able to control whether a service (provided by a worker) is live

Deleting your Worker is probably the wrong tool here. Instead, removing the attached routes from the Worker should be able to ensure that the Worker is not accessible from the internet, which I think should fit your use case? See https://developers.cloudflare.com/workers/configuration/routing/routes/ for more details