You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 13, 2025. It is now read-only.
Add unsafe options for configuring Durable Objects (#573)
Wrangler supports multi-worker development using a dev registry. This
system allows you to reference Durable Objects defined in one process
in another. If we had a Durable Object in worker `a` we wanted to
reference in worker `b`, we could with Miniflare 3:
1. Define a proxy Durable Object in the same process as `b` that
forwarded all requests to `a`'s process, and bind this to `b`
2. In user code, the user could obtain a Durable Object ID and
stub for the proxy object in `b`
3. The user would send a request to this stub, which would proxy to
a worker defined in `a`'s process.
4. This worker would have all `a`'s Durable Objects bound, and we
could obtain a Durable Object ID and stub for the actual object.
5. Finally, we could forward the request to the real stub.
Ideally, the IDs we obtain in steps 2 and 4 would be the same. This
ensures the stub in `b` and instance in `a` share the same ID.
Unfortunately, Durable Object IDs for one object (e.g. the proxy
object in `b`) cannot be used with another (e.g. the actual object in
`a`), _unless_ the objects share the same *unique key*. In this case,
`workerd` effectively treats them as the same object. Normally, this
would be really bad, but these objects are defined in separate
processes, so I think it's ok. The `unsafeUniqueKey` option on
Durable Object bindings allows the unique key to be customised.
An issue with this is that the proxy objects will use this unique key
when persisting their data. The proxy objects don't write any data,
but they still create the databases. This can be confusing, as it'll
look like data for `a` is stored with `a` and `b` (even though `b`'s
copies will be empty). To alleviate this issue, a
`unsafeEphemeralDurableObjects` option has been added which forces
in-memory `workerd` storage for Durable Objects. This gets wiped
between reloads.
0 commit comments