[wrangler] preserve containers config when using versions commands

[KianNH]

Fixes CC-6846

Commands like versions upload were disabling Containers on the associated Durable Object namespaces since the containers property was missing from the metadata JSON.

I swapped the containers property in CfWorkerInit to use ... | undefined like the other properties so TS forces the author to either pass it through or intentionally disregard it.

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: bug fix

A picture of a cute animal (not mandatory, but encouraged)

---

[changeset-bot]

🦋 Changeset detected

Latest commit: 4e3eda9

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[claude]

Claude finished @KianNH's task —— View job

---

Changeset Review

✅ All changesets look good

The changeset file .changeset/lucky-trains-hang.md follows all the guidelines:

1. ✅ Version Type: patch is correct for a bug fix
2. ✅ Changelog Quality: Clear title and explanation of the bug and its cause
3. ✅ Markdown Headers: No h1/h2/h3 headers used
4. ✅ Package Coverage: Both affected packages (wrangler and @cloudflare/workers-utils) are included

The description effectively explains what was broken (Containers being disabled) and why (the property was omitted from the API request body).

---

Note: Reviewer petebacondarwin suggested a slightly refined wording in their review comment, which you may want to consider, but the current changeset is already compliant with all requirements.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 4 additional flags.

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@12368

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@12368

miniflare

npm i https://pkg.pr.new/miniflare@12368

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@12368

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@12368

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@12368

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@12368

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@12368

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@12368

wrangler

npm i https://pkg.pr.new/wrangler@12368

commit: 4e3eda9

[petebacondarwin]

Just the change to the changeset but otherwise LGTM.

[petebacondarwin]

So I think we need some tests updated here?

[emily-shen]

so what happens if config.containers (ie the DO containers enabled flag) has changed on a version upload? like if you set containers = true for the first time. i'm guessing that's ok, you just can't have any code that actually depends on containers or it will all break.

separately, if wrangler config for containers (image, w/e) changes, we should detect and warn users that's not going to do a gradual rollout, like we do with DO migrations, and those changes won't apply until you do wrangler deploy next. we should probably advise people to isolate a version upload and containers changes like we do to get around DO migrations and versions.

i'm guessing the desired behaviour is that when we do a version upload, all the container changes apply in one go when you next do a proper deployment. pretty sure that's fine as-is but can someone try it out and verify that's the case?

[KianNH]

so what happens if config.containers (ie the DO containers enabled flag) has changed on a version upload? like if you set containers = true for the first time. i'm guessing that's ok, you just can't have any code that actually depends on containers or it will all break.

separately, if wrangler config for containers (image, w/e) changes, we should detect and warn users that's not going to do a gradual rollout, like we do with DO migrations, and those changes won't apply until you do wrangler deploy next. we should probably advise people to isolate a version upload and containers changes like we do to get around DO migrations and versions.

i'm guessing the desired behaviour is that when we do a version upload, all the container changes apply in one go when you next do a proper deployment. pretty sure that's fine as-is but can someone try it out and verify that's the case?

I think today a warning is fine since it should hopefully be short-lived, we're going to look at something akin to how we have triggers deploy but for Containers configuration.

That doesn't solve for users having Worker code that relies on being routed to a specific version of their Container but I think we can only really push users to making sure they're writing backwards/forwards compatible changes.

[emily-shen]

i can also see a future where we integrate container rollouts with versions gradual rollouts, but i haven't really thought through the implications of that.