at present it's likely to stay at the same pop. To move to a new pop, you'd have to wait until all cached traces of the old object have been wiped from the system, which could take a while. But we're still working on automatic migration.
doesn't actually do anything in particular anymore. The object keeps running for at least 30 seconds after the last request whether or not use use waitUntil().
Ah. Yes, deferring code to run after the response has already been returned is inherently unreliable, because in the case of a failure, no one finds out. E.g. if the power goes out, the task might never execute, but since the user already received a response, they won't know. Output gates can't help with this, since they can't predict what you're going to do in the future after you return the response. Generally, I don't recommend doing this, except maybe for stuff that is fine to be unreliable, like logging.
specifically parses the output of . It won't work with any string that wasn't specifically created by stringifying an ID from the same namespace. takes any string you want and returns a unique ID corresponding to it.
When I have durable object, let's call it xyz I must use fetch to communicate with it? or could I call it's functions directly? example: xyz.storage.get('key');
It looks like we have some sort of bug where some errors like this happen while we roll out an update to the workers runtime. We are looking into it. (FWIW, whenever you see "internal error" that means we think it's our bug, not yours, and the error has already been reported to our internal monitoring.)