IIRC `waitUntil` doesn't give you more time in a DO
IIRC
waitUntil doesn't give you more time in a DO
HThe request context for a Durable Objects extends at least 60 seconds after the last client disconnects. So waitUntil is not necessary. It remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.
LI have that in progress for my own library (
durable-utils), but not ready yet for any external use. I haven't seen any other library providing that though already.
Aoh interesting. that makes me nervous though... i have some DO code that essentially works like a regular HTTP router and i'm using waitUntil for good measure
Awhy even expose that if it's truly a no-op? 
HIt remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.
HIIRC because many things built for Workers expect
ExecutionContext to existLYour DO will stay active after the last request up to 1-2 minutes if you have some
If you want to keep it running for longer you can schedule an alarm to run every few seconds doing nothing other than checking if your long running tasks are done and rescheduling itself if not yet. Alarms count as normal requests so they reset the timer for eviction.
setTimeout/setInterval scheduled, otherwise it will be evicted after 10 seconds.If you want to keep it running for longer you can schedule an alarm to run every few seconds doing nothing other than checking if your long running tasks are done and rescheduling itself if not yet. Alarms count as normal requests so they reset the timer for eviction.
Awhat about a pending promise?
SHow do you export a DurableObject in a Next.js app using OpenNext on Workers?
LIf you refer to websocket hibernation, then no, you do not pay for duration once the DO is hibernated.
Note that if you use
Note that if you use
setTimeout/setInterval your DO will NOT hibernate regardles if you are using websocket hibernation, hence you will be charged for duration in that case.
Tare there any disturbances with durable objects? One of objects started throwing errors when opening websockets at 18:30 UTC and it still continues. Other instances work fine. All calls to open a websocket end in a error with some internal code, for example:
internal error; reference = keblnpj3s5njtsgrk5tjitk3
JSomehow DO alarms get called everytime i refresh the static page
MHmm, are you maybe setting the alarm to run in the constructor? Alternatively, are you calling the
alarm() handler directly somewhere in your DO code?HNot natively, though you should be able to dump the SQL manually
PI must admit I am still amazed this is not the #1 priority and next feature for DO (I mean native backup/restore procedures through a R2 integration or else).
GGotherwise you could have it write to d1 and use d1s dump feature
AI get DO's that get stuck in an
This has been reported long time ago and marked as resolved but it doesn't look resolved for me: https://github.com/cloudflare/workerd/issues/2993#issuecomment-2801468494
I have tried emptying the
alarm loop. https://screen.bouma.link/r7vljp4v2bMkNb5vJjlTThis has been reported long time ago and marked as resolved but it doesn't look resolved for me: https://github.com/cloudflare/workerd/issues/2993#issuecomment-2801468494
I have tried emptying the
alarm handler and wrapping all it's code in a try/catch. But I don't think I am going to get to the bottom of this without some help 
Smy assumption is still that the outerbase people are cooking something cool in regards of DO storage
SIs this just impossible?
AIs this still an issue that's somehow hidden now? I don't have Smart placement turned on (it's on "default") but I am still getting this
RPC receiver does not implement the method [x] error when I should not be. https://community.cloudflare.com/t/smart-placement-breaks-durable-object-rpc/654797Snot impossible but not recommended anyway workers-and-pages-discussions
Sbut it would require you to change the built code
SThanks! Makes sense.
FHi
In WSL open devtools does not pop up anything, other commands work fine.
Did anyone run into this?
In WSL open devtools does not pop up anything, other commands work fine.
Did anyone run into this?
GI use Durable Objects in remix and I made it so there is a backend worker handling the Durable Object for each customer (they get a unique instance each), and the remix app uses RPC to interface with the worker
SGdispose the stub?
S
GI don't explicitly manage it because the durable object runs on alarms until it completes the queued work
Ggenerally it could be as few as one task to tens of thousands, and remix is not designed for managing that nor would it really make sense given the context
Swell its still good practice and sadly dosent really work in that environment
Glikely, but we only use the RPC to initiate the worker so we end the context very quickly and the documentation says that automatically disposes of it
Gdoing it cleanly is always ideal, but using remix with bindings wasn't super well documentated from what I could find
GI'd love if cloudflare had official demos for these platforms with remix next js etc, showing basic things like database bindings, r2 access etc
FHey all! Do you know of any observability service that could show spans across a worker and a DO? I know baselime used to be the best option in past but idk what the latest is on that since acquisition.
AI have not tried it but I do know Sentry recently released DO support which looks like it supports connected traces: https://github.com/getsentry/sentry-javascript/pull/16180
FThis is coool!
CI'm using Vercel's AI SDK, specifically the streamText function along with createDataStreamResponse, to send custom streaming data. I'd like to integrate this with a Cloudflare WebSocket setup using Durable Objects. What would be the best approach to achieve this integration?
CHi all, whenever I try to write to Durable Object I have in live preview of the logs:
"executionModel": "durableObject", "outcome": "canceled",
CIs there any way to get the information why?
EHey,
I believe I've found a prod vs local discrepancy with Durable Objects - where would I go about reporting this?
I believe I've found a prod vs local discrepancy with Durable Objects - where would I go about reporting this?
LCreate a github issue in the wrangler repo if by local you mean
wrangler: https://github.com/cloudflare/workers-sdk/EThanks - well actually things work as expected locally, just not in prod
LDescribe the issue here, then. Without knowing what the discrepancy is I can't help.
EOk so it does trigger in production 
I think some code is erroring but I've no idea where logs are if an alarm throws an error
I think some code is erroring but I've no idea where logs are if an alarm throws an errorLYou can enable Observability logs for your worker project and you will be able to see your logs in the cloudflare dashboard. https://developers.cloudflare.com/workers/observability/logs/workers-logs/#enable-workers-logs