But afaik if you have any async code in between storage ops there could be issues with concurrency. So like:

ts
const val = await storage.get('something')

await someCode()

await storage.put('something', val + 1)

Could have issues

Essentially, yes. That's it. In the blog post they don't show this, because they wrap the async code and the last

put

in a wrapper

async

function

Basically the gates that block only apply to storage operations and not other async code

But as far as I can get, by just reading the blog post and the documentation's

put

notice, it would seems as it would be "smarter" and understand that the concurrency between the

get

and

put

should be avoided and/or let the following `get`s wait for the last

put

of the previous operation

yup, I wanna test if I can kinda cheat the system tho by just wrapping the

await someCode()

between

blockConcurrencyWhile

Interesting, blockConcurrencyWhile seems to work pretty strange.

ts
this.app.post('/test/concurrency', async c => {
    console.log('Received request in DO', new Date().toISOString())

    await this.state.blockConcurrencyWhile(() => this.timeout(10000))

    console.log('Finished waiting in DO', new Date().toISOString())

    return c.json({ timeout: true })
})

With 2 concurrent requests made both requests take 20s to return, and the console.log for finished was put into the 2nd request for both

Random question: I know

blockConcurrencyWhile

returns a promise, but... do you need to await it to make it work? I am (mistakenly probably) using it without the

await

and seems to work exactly as expected Regarding the logs... Yeah it's pretty strange behaviour

ill test

Looks like you would have to await it. Both my console.logs have the same timestamp if I dont await it. But it does make it return response faster which is interesting

or well I guess it depends

Because if you only want the following code to run after the code in blockConcurrency

what would probably be best is:

ts
this.app.post('/test/concurrency', async c => {
    this.state.blockConcurrencyWhile(() => {
        console.log('Received request in DO', new Date().toISOString())

        await this.timeout(10000)

        console.log('Finished waiting in DO', new Date().toISOString())
    })

    return c.json({ timeout: true })
})

Yup that's probably how I will end up doing it, btw what framework are you using?

This is how I do the DO also if youre curious:

ts
export class TestDO implements DurableObject {
    private app = new Hono<Bindings>()

    constructor(private state: DurableObjectState, private env: Bindings) {
        this.app.get('/', async c => c.text('Hello!'))

        this.app.post('/test/concurrency', async c => {
            this.state.blockConcurrencyWhile(async () => {
                console.log('Received request in DO', new Date().toISOString())
        
                await scheduler.wait(10000)
        
                console.log('Finished waiting in DO', new Date().toISOString())
            })
        
            return c.json({ timeout: true })
        })
    }

    async fetch(request: Request) {
        return this.app.fetch(request, this.env)
    }
}

thanks! 😄

what is

name

supposed to be in

DurableObjectId

, is it supposed to be the name that i generated the id from?

Yes

hmmm, it seems to only give me undefined... ill look at it again tomorrow

Actually, I'm not 100% sure. I know that in some cases the name of a DO ID is unrecoverable.

So maybe that's why?

i feel like it wasn't there before? maybe it's new an my DO is on an old version?

Maybe. But I do know that it won't always be there(like when you use

newUniqueId()

), so I'm not 100% how it is generated/persisted.

name was definitely not a thing before, and I thought they said it wouldnt be supported so you'd have to pass the name into the DO yourself but interesting if they added it 🤔

well thanks anyway, ill look at it more tomorrow

name will be defined on the id you get back from idFromName in the eyeball worker

name will not be defined on the id you get back from this.state.id in the durable object

name will (obviously) not be defined on the id you get back from newUniqueId in the eyeball worker

tldr if you need the name in the DO, pass it in the request. this hasn't changed

If I'm using

addEventListener

, do I access the environment from global...

export interface Env {
  MY_DURABLE_OBJECT: DurableObjectNamespace;
}

addEventListener('fetch', (event) => {
  MY_DURABLE_OBJECT.foo
});

How do I correctly handle that for TypeScript? is this the correct way?

declare global {
  MY_DURABLE_OBJECT: DurableObjectNamespace;
}