Container app deploys without DO namespace linkage due to circular Output dependency in bindContainer

[yovanoc]

Summary

When binding a Cloudflare.Container to a Cloudflare.DurableObjectNamespace via Cloudflare.Container.bind inside a DO class body, the container application is created in Cloudflare's control plane without its Durable Object namespace linkage. Runtime consequence:

Error: There is no container application assigned to this Durable Object namespace

The container is endlessly restarted by StartContainer.ts's exponential retry loop, silently masking the real error.

Environment

• alchemy@2.0.0-beta.9 (reproduces on fork yovanoc/alchemy-effect-fork@2282ff3, same code on upstream main)
• effect@4.0.0-beta.48
• @cloudflare/workers-types latest
• Bun runtime, macOS darwin
• Pattern: canonical Container Layer — class + .make() in separate files, DO imports class

Reproduction

Canonical pattern from the Container docstring:

// src/containers/device.ts
export class DeviceContainer extends Cloudflare.Container<DeviceContainer>()("DeviceContainerApp", {
  main: "./src/containers/device/server/server.ts",
  runtime: "bun",
  instanceType: "dev",
}) {}

// src/containers/device-do.ts
export default class DeviceContainerDO extends Cloudflare.DurableObjectNamespace<DeviceContainerDO>()(
  "DeviceContainer",
  Effect.gen(function* () {
    const container = yield* Cloudflare.Container.bind(DeviceContainer);
    return Effect.gen(function* () {
      const started = yield* Cloudflare.start(container);
      const port = yield* started.getTcpPort(3000);
      return {
        fetch: Effect.gen(function* () {
          const request = yield* HttpServerRequest;
          return yield* port.fetch(request);
        }),
      };
    });
  }),
) {}

Deploy succeeds cleanly. Any invocation of the DO that reaches Cloudflare.start(container) triggers the runtime error above.

Evidence

Alchemy state file .alchemy/state/<app>/<stage>/DeviceContainerApp.json:

{
  "attr": {
    "applicationId": "a03a9b73-d707-42bb-b301-1f61457d943a",
    "durableObjects": null          // ← should contain { namespaceId: "..." }
  },
  "bindings": [
    {
      "sid": "DeviceContainer",
      "data": {
        "durableObjects": {}         // ← should contain { namespaceId: "<resolved>" }
      }
    }
  ]
}

Worker tail logs repeat every ~2 min:

INFO (#41): Container not running, starting...
INFO (#41): Container started, launching monitor
INFO (#53): Container monitor exited
Error There is no container application assigned to this Durable Object namespace

Root Cause Analysis

A circular Output dependency between Container and DurableObjectNamespace:

1. DurableObjectNamespace.ts:585-596 — self.namespaceId is an Output<string> that resolves via worker.durableObjectNamespaces.pipe(Output.map(ns => ns?.[name])). It resolves only after the Worker has deployed (Worker is what populates durableObjectNamespaces).

2. ContainerBinding.ts:32-36 — bindContainer calls:

   yield* container.bind`${namespace}`({
     durableObjects: {
       namespaceId: namespace.namespaceId,   // Output<string>, unresolved
     },
   });

3. Apply.ts:451 — When the ContainerApplication is about to create, Output.evaluate(node.bindings, outputs) runs. But the Container is an upstream dependency of the Worker (Worker binds to Container). So at Container-create time, the Worker hasn't deployed and worker.durableObjectNamespaces[name] is still undefined. Output.evaluate resolves namespaceId to undefined.

4. ContainerApplication.ts:871-888 — getDurableObjects(bindings):

   const dos = bindings.flatMap((b) =>
     b.data.durableObjects ? [b.data.durableObjects] : [],
   );
   if (dos.length === 0) return Effect.succeed(undefined);
   if (dos.length === 1) return Effect.succeed(dos[0]);

   b.data.durableObjects = { namespaceId: undefined } is truthy, so the function returns { namespaceId: undefined } instead of undefined.

5. ContainerApplication.ts:1038 — createApplication is called with durableObjects: { namespaceId: undefined }, which serializes the namespaceId field away. Cloudflare's API receives a malformed/empty DO attachment and creates the app without linkage.

6. ContainerApplication.ts:985-988 — The recreate-on-DO-change guard:

   if (output && !adoptPolicy && !deepEqual(output.durableObjects, durableObjects)) { ... }

   After the first deploy, output.durableObjects === null and durableObjects === { namespaceId: undefined }. Subsequent deploys hit this check: both sides deep-equal to "nothing meaningful" under JSON round-tripping, so the guard never fires and the broken state persists across all future alchemy deploy runs (including --force).

Intent vs Reality

The precreate/create split at ContainerApplication.ts:933-966 includes this comment:

Precreate intentionally omits the Durable Object attachment so the worker can bind to this application id and break the circular dependency. The final create step recreates the application with the resolved namespace when needed.

The intent is correct: precreate without DO linkage → Worker deploys → Worker populates durableObjectNamespaces → create re-runs with resolved namespaceId → recreate the app with linkage.

But there is no ordering mechanism that re-evaluates the Container's bindings after Worker deploy. Apply.ts evaluates bindings once at create time against currently-resolved outputs. Because Container is upstream of Worker in the dependency graph, the Worker's durableObjectNamespaces is never available when Container's bindings are evaluated.

Suggested Fix Directions

Not submitting a patch because the fix likely requires a framework-level decision, but options:

1. Make DurableObjectNamespace declare the container linkage directly. Instead of having bindContainer push { namespaceId: <unresolvable Output> } into the container's bindings, have DurableObjectNamespace itself (which knows its own namespaceId resolution path) push the linkage. This inverts the dependency so the Output producer (Worker/DONamespace) is downstream of its consumer (Container's DO attachment).

2. Two-phase container create: after Worker deploys and DO namespace IDs are known, re-invoke the Container provider's update path with the now-resolved bindings to patch in the DO linkage. Requires Apply.ts changes to support a "post-worker" re-evaluation pass.

3. Fail loudly at create time: if getDurableObjects(bindings) returns a shape with namespaceId === undefined, Effect.die with a clear message instead of silently serializing a broken payload. This at least surfaces the bug during alchemy deploy instead of only at runtime.

Happy to contribute a patch once the preferred approach is agreed upon.

Workaround

None found. Manual CF API attachment of DO namespace to container application drifts on next deploy (alchemy state overwrites). Downgrading to Worker-only architecture (no containers) avoids the path entirely.

Related Files

• packages/alchemy/src/Cloudflare/Container/ContainerBinding.ts (lines 32-36)
• packages/alchemy/src/Cloudflare/Container/ContainerApplication.ts (lines 871-888, 933-1045)
• packages/alchemy/src/Cloudflare/Workers/DurableObjectNamespace.ts (lines 585-596)
• packages/alchemy/src/Apply.ts (line 451)

[yovanoc]

Opened #73 as a draft with a minimum-viable fail-loud fix in getDurableObjects. It does not resolve the underlying circular Output dependency (that needs maintainer direction on the preferred structural approach, outlined in this issue), but it converts the current silent deploy-time failure into a loud diagnostic so users aren't chasing a runtime error with no signal.

Happy to follow up with a larger PR on whichever structural direction you prefer.

[sam-goodwin]

Can you share a repro for this? I've had issues here before but my cloudflare-worker containers example was working last time I checked. Apply is meant to converge the graph

[yovanoc]

Thanks for the quick look! A couple of data points from digging in.

1. The cloudflare-worker-containers example isn't on alchemy-effect/main — examples/cloudflare-worker-containers returns 404 on alchemy-run/alchemy-effect#main. The only extant container example I can find is examples/cloudflare-container on the legacy alchemy-run/alchemy repo, which uses the await alchemy(...) API where the DO is a standalone top-level resource created before the Worker — different resolution path from the Effect API.

If you have a working alchemy-effect container example in a branch / gist, could you point me at it? It's possible I'm looking at a stale snapshot.

2. Concrete failure trace on the Effect API — deterministic on a clean alchemy@2.0.0-beta.9, using the pattern from Cloudflare.Container.make's own docstring:

class DeviceContainer extends Cloudflare.Container<DeviceContainer>()("DeviceContainerApp", {
  main: "./src/containers/device/server/server.ts",
  runtime: "bun",
  instanceType: "dev",
}) {}

export default class DeviceContainerDO extends Cloudflare.DurableObjectNamespace<DeviceContainerDO>()(
  "DeviceContainer",
  Effect.gen(function* () {
    const container = yield* Cloudflare.Container.bind(DeviceContainer); // ← bind happens here
    return Effect.gen(function* () {
      const started = yield* Cloudflare.start(container);
      const port = yield* started.getTcpPort(3000);
      return {
        fetch: Effect.gen(function* () {
          const request = yield* HttpServerRequest;
          return yield* port.fetch(request);
        }),
      };
    });
  }),
) {}

Inside bindContainer (Cloudflare/Container/ContainerBinding.ts:32-36):

yield* container.bind`${namespace}`({
  durableObjects: {
    namespaceId: namespace.namespaceId,   // Output<string>
  },
});

But namespace.namespaceId is derived from worker.durableObjectNamespaces (DurableObjectNamespace.ts:585-590) — an Output that only resolves after the Worker's create/update API call lands. The Container resource is a dependency of the Worker, so apply creates the Container first, passing { namespaceId: undefined } (unresolved Output rendered as undefined) into getDurableObjects in ContainerApplication.ts (around L900-L915). Without the fail-loud patch from #73, this silently forwards undefined to the CF API and the container application is created with durableObjects: null in state — the runtime then errors no container application assigned to this Durable Object namespace and the DO instance is restart-looped by StartContainer.ts.

State-file evidence from a clean deploy against upstream main (pre-patch), attr after a successful create:

{
  "attr": {
    "applicationId": "a03a9b73-d707-42bb-b301-1f61457d943a",
    "durableObjects": null
  },
  "bindings": [
    { "sid": "DeviceContainer", "data": { "durableObjects": {} } }
  ]
}

3. What I think is happening

apply does converge for the case where the Container's DO consumer is an independent resource (the legacy pattern — the DO is created first, namespaceId resolves, then the Container goes in). But when the DO is registered as a binding inside the Worker's init Effect (the Effect API pattern shown in Container.make's docstring), the namespaceId's Output chain now flows through the Worker's post-create attrs, so it cannot resolve at the point where the Container resource's diff runs. A precreate/adopt phase on ContainerApplication that defers the durableObjects attachment until after the Worker lands would break the cycle; #73 only converts the silent failure into a loud diagnostic so users aren't chasing a runtime error with no deploy-time signal.

Happy to put together a tiny standalone repro repo this week if it helps — do you want me to target legacy alchemy-run/alchemy, or land it under alchemy-effect/examples/cloudflare-worker-containers?

[sam-goodwin]

The example is in examples/cloudflare-worker on main

[sam-goodwin]

https://github.com/alchemy-run/alchemy-effect/blob/main/examples/cloudflare-worker/src/Sandbox.ts

[yovanoc]

Opened draft PR #84 with a minimal reproduction: examples/cloudflare-worker-paired-do.

Paired-DO + split-runtime pattern. Deploy succeeds, state shows durableObjects: null, runtime errors no container application assigned to this Durable Object namespace. README covers the repro + mandatory LogicalId mismatch workaround ("MyContainerApp" vs "MyContainer").

Complements #73.