And everything works fine inside

wrangler dev

are you using environments in your wrangler.toml file? IIRC the durable_objects section is not shared across environments

Just one: https://github.com/RafalWilinski/cloudflare-chat/blob/graphql/wrangler.toml

I mean, no custom environments

And the DOs are exported here: https://github.com/RafalWilinski/cloudflare-chat/blob/graphql/src/index.ts#L68-L71

I’ll look into this and get back to you

@Rafal You need to have both

ChannelsDO

and

ChannelDO

in your migration:

[[migrations]]
tag = "v1"
new_classes = ["ChannelsDO", "ChannelDO"]

Added, both, same effect

Ah since you’ve already uploaded before the migration tag of the script is already v1 and so changing the contents of the migration in wrangler.toml won’t do anything — easiest thing to do is to delete the script with

wrangler delete

and publish again

That worked!, thanks! But the error message was quite misleading

But it made me thinking - how such situation should be handled in production case, I mean when I cannot do

wrangler delete

?

this is caused by editing migrations that have already been uploaded — you could also make a migration with tag = v2 that adds the missing class

Are there any updates about how to use DO in Pages (with Remix). ? I've seen this comment in github using _worker.js but not sure how it works: https://github.com/remix-run/remix/discussions/3066 Is there any repo with examples available? Thx

@JacobParis In this article you mention How to use DO with wrangler, but it doesn't work for me. https://www.jacobparis.com/guides/cloudflare-remix#durable-objects I always get this error :

[pages:err] DurableObjectError [ERR_CLASS_NOT_FOUND]: Class "List" for Durable Object "LIST" not found
    at DurableObjectsPlugin.reload (C:\trials\remix-pages\node_modules\@miniflare\durable-objects\src\plugin.ts:316:15)

It's like what is said in github above: the export class in the server.js doesn't export the class

I think I did end up using a separate worker for the DO

I think I had to use wrangler 1 to deploy the DO and then I switched back to wrangler2 for everything else

But that was a long time ago I forget exactly

Has anyone figured out how to do a durable object transfer migration from one worker to another, using wrangler.toml [migrations] ?

docs say: > Transfer migrations are used to transfer stored objects between two Durable Object classes in different scripts. and wrangler publish seems to support

--transfer-class <from script> <from class> <to class>

But I don't see a way to do same using the toml file.

actually, looks like that deprecated CLI approach has already been removed from wrangler

hm, wrangler 1 sources look something like something like this is supported:

transferred_classes = [{from_script = "...", from="(class name)", to = "(class name)" }]

but I don't think support for this has made it to wrangler 2. Which makes me wonder if transfer migrations are still supported at all, in which case I think the docs should be updated to remove reference to them

hm, wait .. even though wrangler complained about it (

- Unexpected fields found in migrations field: "transferred_classes"

), it actually looks like using transferred_classes in wrangler.toml worked

Would you mind filing an issue on the wrangler2 github repo about this, so the team can take a look?

Ok, no problem

I retested this with a fresh pair of workers and got the same result, so I've filed the issue: https://github.com/cloudflare/wrangler2/issues/2305

I can see the cost of this approach adding up, at scale. Unless i've miscalculated, hourly snapshots of just 5.3MB of durable object storage will cost 20c / month in storage read operations. Daily snapshots of 128MB would cost the same. I've been pondering the use of some sort of mutation log, which would have to be stored within the durable object itself (for consistency), and then periodically flushed out to R2. That would allow a point-in-time rebuild of a durable object, at the cost of additional storage operations and redundant storage of overwritten data (although the log could be periodically flattened beyond a certain time window)

@David Hogan That's a really good idea! A lot of things with DOs can get really pricey as operations and data sizes scale ... @Ceru © have you thought about this at all before? Something like this could be a very valuable primitive / base DO class ...

Mutation log is exactly how dynamodb does PITR and you can use it as an ordered event stream 🙂

Hi! Question: I have a large in-memory object that is instantiated inside the DO constructor. Clients connect to the DO via a websocket and send incremental updates to this state. I'd like to persist these updates in the DO persistent state, but I'd rather not incur the cost of writing to disk for each and every incremental update. Ideally, I'd have some listener that would fire before the DO is evicted from memory, at which point I could write the in-mem object to disk. Is this possible?

No, because while some evictions can be predicted, others may be spontaneous, so you should be prepared to be evicted after any request