Workers do not access the same instance of Durable Object #461
Labels
behaviour mismatch
Different behaviour to Workers runtime
Comments
mrbbot
added a commit
that referenced
this issue
Feb 16, 2023
A core guarantee of Durable Objects is global uniqueness: there will only ever be a single instance of a Durable Object class with a given ID running at once. Miniflare stores instances of Durable Objects in instances of `DurableObjectsPlugin`. These object instances get reset on every script change. If a stub attempts to fetch the object again, a new instance will be created with the new code. Unfortunately, each mount has its own `DurableObjectsPlugin`, meaning stubs in each mount were unable to see instances created by other mounts, and hence created their own. This broke global uniqueness. This change introduces the concept of a `sharedCache` between all mounts in a `Miniflare` instance. This is created when `new Miniflare()` is called, then passed to all mounts and all their plugins via context. The parent `Miniflare` instance will clear this after all `beforeReload()`/`dispose()` hooks have run. `DurableObjectsPlugin`s now use this to store active instances and their corresponding storages.
mrbbot
added a commit
that referenced
this issue
Feb 17, 2023
A core guarantee of Durable Objects is global uniqueness: there will only ever be a single instance of a Durable Object class with a given ID running at once. Miniflare stores instances of Durable Objects in instances of `DurableObjectsPlugin`. These object instances get reset on every script change. If a stub attempts to fetch the object again, a new instance will be created with the new code. Unfortunately, each mount has its own `DurableObjectsPlugin`, meaning stubs in each mount were unable to see instances created by other mounts, and hence created their own. This broke global uniqueness. This change introduces the concept of a `sharedCache` between all mounts in a `Miniflare` instance. This is created when `new Miniflare()` is called, then passed to all mounts and all their plugins via context. The parent `Miniflare` instance will clear this after all `beforeReload()`/`dispose()` hooks have run. `DurableObjectsPlugin`s now use this to store active instances and their corresponding storages.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
Currently, Miniflare does not reuse the same
DurableObjectsPluginacross workers. However, that's not how the production Durable Objects behave. There is only one instance of a Durable Object, as the documentation explains in the sections "Durable Object lifespan" and "In-memory state" from https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#durable-object-lifespan.I wrote a (very) simple patch to make it work and fixed one unit test. But I couldn't figure out how to fix
packages/core/test/index.mounts.spec.ts. I didn't understand enough the initialization of Miniflare in those tests. Here's the relevant commit:grafbase@35cabda
The text was updated successfully, but these errors were encountered: