but i dont know if the state is reset

it would make sense for the state to reset as it could lead to corruption and such but ive never got the chance to test it personally

would it be possible to somehow use a snowflake as id?

i guess you'd just do an

idFromName

"i believe the DO is reset upon code change" - this is not the case. the underlying storage remains, even if the DO code changes

got it, thanks!

elixir
class Ring {
  async fetch(request) {    
    if (!this.initializePromise) {
      this.initializePromise = this.initialize().catch((err) => {
        this.initializePromise = undefined;
        throw err
      });
    }
    await this.initializePromise;
    this.do_tick();
    ...
  }

  do_tick() {
    if (this.tickPending)
      return;
    this.tickPending = true;
    setTimeout(tick, 1000);
  }
  async tick() {
    setTimeout(tick, 1000);
  }
}

Does this look sane? I want to have a 1 second tick inside my DO, if the DO shutsdown+spinsup, itl start ticking.

How do you do a get request into a DO with a custom url?

i hardcoded a url and ended up calling another worker lol

nm seems i can use "/path" only

without https

and this causes is to go to the DO instead of to a worker

is there a way to bulk read a bunch of keys or do I have to do it one by one

Call

storage.get

with an array of strings and it returns a map promise. Any missing values are omitted from the result map. (supports up to 128 keys at a time)

does DO have a KV-style TTL yet that autodeletes it after a time period?

@User I had the same question, and there's nothing listed in the API docs - autodeleting storage elements could have been useful!

can i fire multiple fetches against a DO stub in parallel and have them all resolve at once? If so, what, if any part of that enforces order? Same with multiple workers accessing the same DO at the same time with parallel fetches...

the DO doesn't really have a URL to speak of, because it can't be accessed directly from the internet, only from a DO stub within a worker/other DO (@cf guys feel free to jump in if I'm speaking out of my @$$), so any url is fine, it's just the bit that the DO fetch will see/parse/do something with

so most cases I've seen (and what I do) is use a fake/trash domain, and just parse the path from the DO

Yea but when I used a full https url, the request seems to go to my worker, not the DO.

switched to only the path portion /path it correctly went to the DO now

Are you sure about this one? I am in some cases just passing the original request

i guess i can check it again, original request works fine. I had a worker on 2.zod.tv, and i called a do like obj = CLASS.idFromName("name"); obj.fetch("https://1.zod.tv/path", params) and the request seemed to go to 1.zod.tv/path which was another worker.

this was from inside a DO btw

so DO calling DO

Only guarantee I've seen re: call ordering is the ordering within a single stub client. i.e. calls from that stub will arrive in order on the DO side (or fail) https://developers.cloudflare.com/workers/runtime-apis/durable-objects#object-stubs

but since each request is async, do they just guarantee arrival order (async commands within each fetch round trip may execute at diff times), or does each fetch actually fire AND resolve before the next fetch is allowed to call it?

just curious which if any race conditions we'll need to deal w

Right, only arrival order is guaranteed. If the event handler awaits some I/O, the next event can be delivered in the meantime.

So I guess if we need more, we implement a form of transaction lock inside the DO for fetches to check against?