Oh here is a new one: "Error: cannot access storage because object has moved to a different machine" Is there a list of these somewhere...?

You can probably just always retry not sure matching against every error message is the best way

Hmm I suppose that could work. I got this idea from some code somebody else posted here a while ago

What is the billing like though for deleting multiple keys? I was under the impression that it would be a delete request per key? So if I deleting say 100million keys one by one is $100. Would deleting them in batches of 50 still be $100, or would it be $2?

anyone know why my error handling seems to not actually be working: https://github.com/kwhitley/itty-durable/compare/v1.x...sathoro:itty-durable:v1.x#diff-97a933af0fb78f328d569be08bd44008f49fcffac639b9a9aaf37e114b346a2d

I would assume that it is billed as one operation because in my previous message I raised concerns about the costs: https://discord.com/channels/595317990191398933/773219443911819284/1099362651135557765 but ideally we would get an official confirmation 🙂

Every operation that does multi-key is still billed the same as if it was an individual operation on each. See: > Requests that hit the Durable Objects in-memory cache or that use the multi-key versions of get/put/delete methods are billed the same as if they were a normal, individual request for each key.

And you can also actually see the code where they add the deleted count in

deleteAll

on workerd source: https://github.com/cloudflare/workerd/blob/main/src/workerd/api/actor-state.c%2B%2B#L498

Thank you for the clarification, @Unsmart | Tech debt!

It's still $100

i havent actually worked with durable objects but im trying to get a good mental image. Is it possible to give some sort of info to a durable object alarm? For example if i want to create a

!remindme ...

command for a discord bot then ideally i would set a durable object alarm to the specified time but then when the alarm goes off how would i get the message that the user specified? How would you know what the message was for this specific alarm?

because originally i thought you could set an alarm and some small info, like a short string or json object. Then when the alarm goes off you would get that info so you'd know some context. reading the docs it doesn't seem to be a thing

The way that libraries do it (like ) is by putting the 'context' into storage which can later be retrieved by the alarm.

If you're interested in implementing it yourself then the code there is a good start, otherwise you can just use the library.

hmm yeah i figured just putting something in storage. but then i was wondering how precise the timing of a alarm is, because if the context is under the timestamp of the alarm and the alarm was not exactly on time then you'd miss/lose the context

but ill check out that code to see how other people deal with this

thanks!

Hi folks, my worker doesn't want to deploy on github actions because of this message. How do I fix it?

In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects

By going to that link it sent and agree to pricing

I'm not sure what to replace the dots with

your account id

that URL is wrong, I had to go to https://dash.cloudflare.com/accountId/workers/services/view/myWorker/production, then scroll to the bottom and enable it there

The TL;DR is that you use

list

, not

get

to get the context from storage. And then at the end of the alarm set the next alarm for the next item in the list. Now alarms are pretty accurate normally, but obviously can't be millisecond accurate even then. But in the case of outages for example, it might take a few minutes for an alarm to fire again.

But have a look at the library, it should do pretty much exactly what you want. Either use it or feel free to rip out the code that you need 🙂

So, we can use Rxjs Inside a Worker? I'm triyng to make it work but seems to not to work

you technically can! https://github.com/davidbarratt/drupal-edge/blob/78ee14c44ae70fd3861697e9f6b059be7d275d75/src/cache-tag.ts#L27

thanks @davidbarratt , what I'm trying is to use a worker as SSE server. Viewing other examples of the SSE implementation, I think they used a setInterval to maintain live the worker and not close the connection. What I'm trying is use the same worker as webhook receiver so fetch data -> send via SSE. For that and communicate the requests to send to the SSE response , I'm use an Rxjs Subject so: 1. request --> send to observer . 2. the subscriber object get the new data from the observer and send the data via SSE. Problem here is that probably the setInterval is blocking other executing code, because the writer inside the subscriber is never trigged

`
export const sseController = () => {
  const { readable, writable } = new TransformStream();
  const headers = new Headers();
  headers.append("Content-Type", "text/event-stream");
  headers.append("Cache-Control", "no-cache");
  headers.append("Connection", "keep-alive");
  headers.append("Access-Control-Allow-Origin", "*");
  headers.append(
    "Access-Control-Allow-Headers",
    "Origin, X-Requested-With, Content-Type, Accept"
  );
  const init = { status: 200, statusText: "ok", headers: headers };
  const encoder = new TextEncoder();
  const writer = writable.getWriter();

  NewLog$.subscribe(async (message: any) => {
    writer.write(encoder.encode(`data: ${message}\n\n`));
  });

  setInterval(() => {
    writer.write(encoder.encode(`data: ${msg}\n\n`));
  }, 5000);

  return { init, readable };
`

We call this controller and then construct the response with

return new Response(readable, init);

https://developers.cloudflare.com/workers/platform/limits/#durable-objects

Durable Objects scale well across Objects, but each object is inherently single-threaded. A baseline of 100 req/sec is a good floor estimate of the request rate an individual Object can handle, though this will vary with workload.

The text refers to object instances, right? So if there are 1000s of DO instances, they each get 100 req/sec, right? We don't need nearly as much per instance, but a 100 req/sec limit across all instances of a DO would be a problem.

Yes, each instance would have its own concurrency limits. The 100 req/s isn't a hard limit by any means, but just a good baseline to keep in mind

How persistent is the Transactional storage API for durable objects? If a durable object isn't used for a couple hours or a day, and then it is reconstructed and calls the storage API, will it still get the previous value? What are the limitations around this?