CC-8364 Support Durable Object container settings and exports - #15597
CC-8364 Support Durable Object container settings and exports#15597skepticfx wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: dc4afa8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 10 packages
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 |
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/codemods
@cloudflare/config
@cloudflare/containers-shared
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-plugin
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
|
LGTM |
5269712 to
b96799e
Compare
b96799e to
2098bc7
Compare
Resolve name-only Durable Object-managed Containers through declarative exports for validation, image preparation, version metadata, and application reconciliation. Apply explicit application-wide flags and log settings on deploy using POST for missing applications and PATCH for existing ones. Preserve omitted settings, existing settings during version commands, and rollout-none behavior. Cover name-only exports with settings across application creation, updates, uploads, and version deployment.
2098bc7 to
dc4afa8
Compare
| ): Promise<void> { | ||
| let existing: DurableObjectApplicationState; | ||
| try { | ||
| existing = await ApplicationsService.getApplication(namespaceId); |
There was a problem hiding this comment.
🔴 Existing applications look missing
On redeploy, applyApplication queries the application endpoint with a namespace ID. Application stores its ID and namespace separately, so Wrangler retries creation and fails on the duplicate.
Learn more
The application API addresses GET /applications/{application_id} by application ID. A Durable Object-backed application stores that ID separately from durable_objects.namespace_id in Application. The code only has a namespace ID here, so a previously created application is not reliably addressable through this endpoint. A 404 then enters the create path, where the namespace already owns an application and the deployment fails instead of updating or preserving settings.
Example: Namespace ns-123 owns application app-456. A second deploy requests /applications/ns-123, receives 404, and POSTs another application for ns-123; the API rejects it as already attached.
Recommended fix: Resolve the application by its Durable Object namespace before calling getApplication or modifyApplication. Use an SDK endpoint that filters by namespace if available, or list applications and match durable_objects.namespace_id, then retain the returned application.id for PATCH. Preserve the existing identity checks against the matched application.
Was this helpful? React with 👍 or 👎 to provide feedback.
Fixes #CC-8364
Resolve name-only Durable Object-managed Containers through declarative exports for validation, image preparation, version metadata, and application reconciliation.
Apply explicit application-wide flags and log settings on deploy using POST for missing applications and PATCH for existing ones. Preserve omitted settings, existing settings during version commands, and rollout-none behavior.
Cover name-only exports with settings across application creation, updates, uploads, and version deployment.