when using the storage.put method and passing an object with multiple key and values, what should that object look like? i'm doing something like { somekey: somevalue, anotherkey: anothervalue } but it doesn't seem to be working properly. does it need to be { "somekey": somevalue, "anotherkey":anothervalue} or something else?

Are you JSON.stringify-ing your data being stored?

isn't the point of DOs that you don't have to do that?

wdym by it doesn't seem to be working properly?

await storage.get('somekey')

isn't working?

the main point of DO is consistency not json.stringify or not if you can even save it as a value other than a string

the other main point is in the name - "objects"

> Each value can be any type supported by the structured clone algorithm, which is true of most types.

As in the data doesn't seem to get stored at all but i think the problem is that line of my code that calls to the DO isn't being executed when deployed but does when using wrangler dev 😭 no idea why but it's breaking the whole thing as values in the DO are leaking now

Whats the code you are using? and did you try JSON.stringify? maybe they have an issue where its not actually storing object values like it should

Also I had no idea wrangler dev worked for DO thought it didnt must have added it in somewhat recently and I missed it lol

Can a DO be bound somehow to a fetchevent worker? I tried already to build a module based worker, deploy it with new-class and then bind the DO to the fetchevent worker but could not get it working.

It cannot. You need to use modules to use DO. Hopefully wouldn't be too much work to convert the service worker Worker?

Alright thanks! The conversion was no problem, but on the module based worker the request.cf property is empty and I was using the geolocation data. Is this not available anymore?

Think I've seen someone talking about that before. If the entrypoint Worker's

request.cf

is empty, then that's a bug for sure. Not sure if the team have been properly alerted (cc. @User ?). But within the DO fetch handler, I imagine that could be empty, since it's not a real over-the-internet request that it handles.

Yup I'm not talking of the request in the DO. It's the request.cf in the default export of the worker which uses the DO. That's why I thought my option would be to switch back to the fetchEvent 😄

Didn't do a bug report so far - what would be the channel for this?

Albert'll hopefully catch this on Monday and pass it on to the team to investigate 🙂

fwiw: https://discord.com/channels/595317990191398933/773219443911819284/834500066222800906

you have to actually publish the DO, so not great in terms of testing offline but helps when you need some console logs 🙂

is it normal for communication with the DO to sometimes take 30 seconds? one of my calls sometimes does and it's not doing much apart from storing two values

I am noticing wierd state bugs where if a DO shuts down or not, it stops processing setTimeout

at a certain point a DO stops processing setTimeout even tho its state has not been reset

the only fix is to redeploy the DO

javascript
class DOClass {
  do_tick() {
    if (this.tickPending)
      return;
    this.tickPending = true;
    setTimeout(() => this.tick(), 1000)
  }
  async tick() {
    try {
      await this.delegate_jobs();
    } catch (err) {
      this.broadcast(JSON.stringify({opcode: err.message, stack: err.stack}))
    }
    setTimeout(() => this.tick(), 1000)
  }
}

code like this

where, do_tick is called by every connecting websocket

eventually stops ticking

but this.tickPending == true, meaning the DO did not shut down

(since a shutdown DO would reset its state)