That would be with `transaction()/transactionSync()`
That would be with
transaction()/transactionSync()
JFor example we could have an outbox table:
- Transaction starts;
- Change/delete a row (Output Gate closed);
- Send the message to an external system (Request blocked by the Output Gate. Deadlock?);
- Receive a response;
- Transaction commit/rollback depending on the response;
JRight now I think we would have to lease the message and send it outside of the transaction, and then the consumer would have to
ack
LTLDR: If the callback given to those functions throws, the transaction is rolled back. Anythinh done outside in external systems is up to you to stay consistent.
JSo there is no way currently to make outgoing connections inside a transaction?
JWith SQLite
JIn most cases this would be a bad idea, but in the scenario I described above it should be reasonable and a simpler design
LI wrote this a few years back before
transactionSync()Medium
Cloudflare durable objects maintain consistency in light of storage write failure, but not when your code throws an unexpected error.
VCan a bidirectional channel service built on the QUIC protocol ( like WebTransport) be used in durable objects?
Mhey all, quick docs question
im using the cloudflare adapter with sveltekit (which works via
and this section provides instruction on using
https://developers.cloudflare.com/workers/wrangler/api/#supported-bindings
however after setting up this way i'm seeing this error trying to call RPC methods on the stub:
the docs from the link above say this, but I'm wondering if that "not" (fourth word along) should not be there? and instead should it read "If you ARE using..."
im using the cloudflare adapter with sveltekit (which works via
getPlatformProxyand this section provides instruction on using
script_namehttps://developers.cloudflare.com/workers/wrangler/api/#supported-bindings
however after setting up this way i'm seeing this error trying to call RPC methods on the stub:
the docs from the link above say this, but I'm wondering if that "not" (fourth word along) should not be there? and instead should it read "If you ARE using..."
If you are not using RPC with your Durable Object, you can run a separate Wrangler dev session alongside your framework development server.
Otherwise, you can build your application and run both Workers in the same Wrangler dev session.
HNo, not at this tim
1Are there any plans to add the 
)
agent
VDoes this mean that it will be integrated into this protocol in future plans ? Or can only be built using WebSocket ？
HI’m not sure. I’m not on the Durable Objects team. I only say Not at this time because I can’t guarantee that the team isn’t planning to implement it at some point
Vgot it , thank u !
Muploaded a very small repo showing that i cant get durable object bindings working with
https://github.com/mattfysh/cfdo
getPlatformProxyhttps://github.com/mattfysh/cfdo
Mfollowing these instructions: https://developers.cloudflare.com/workers/wrangler/api/#supported-bindings
but whenever I try to invoke the DO, i just get a 503 Service Unavailable
but whenever I try to invoke the DO, i just get a 503 Service Unavailable
Mplease take a look 
really unsure how im supposed to work locally with durable objects
really unsure how im supposed to work locally with durable objectsMis there an example repo somewhere?
Mah i see the problem -- there is no test using the
https://github.com/cloudflare/workers-sdk/tree/main/fixtures/get-platform-proxy
so it probably never worked
wrangler_external_do.jsonchttps://github.com/cloudflare/workers-sdk/tree/main/fixtures/get-platform-proxy
so it probably never worked
Mcool 
real fun wasting a whole day on this
real fun wasting a whole day on thisMin fact the only test that does use that fixture is just making sure the "internal" binding warning does not appear: https://github.com/cloudflare/workers-sdk/blob/4259256e33445b5f2ae290a68795be9c1852d860/fixtures/get-platform-proxy/tests/get-platform-proxy.env.test.ts#L286-L291
No one thought to actually then go ahead and test that the DO binding actually worked?
No one thought to actually then go ahead and test that the DO binding actually worked?
LThe
You can use it on its own inside any
@cloudflare/actorsYou can use it on its own inside any
DurableObjectThat's brilliant thank you, I have a large Worker which uses agents and json-rpc-mixin which made the whole thing really heavy dependency wise. Now I can move to actors and lumenize
KIs there a way I can know if there's durable object already present with specified name/id?
or new one needs to be initialised?
or new one needs to be initialised?
1The GraphQL API can let you filter a list of objects by
DurableObjectIDAccountDurableObjectsSqlStorageGroupsAccountDurableObjectsStorageGroups
JThe problem here is that I want to communicate with the external world while state is not durable, more specifically inside
transactionSync()I didn't test this yet, but I'm guessing that if I try to make a
fetchtransactionSyncCommunicating with outside world immediately means it's not sync though 
JYeah, I'm talking about SQLite, it could be inside a
transaction()How can I achieve this with SQLite?
LHave you tried the
transaction()In order for that to be most useful from a DO, Cloudflare will also have to implement the equivalent of hibernating WebTrasport. It's on my wishlist too, but from what I understand, outside of WebRTC, Cloudflare has limited support for QUIC anywhere, so it'll be a while before that trickles all the way down to DOs.
LThat sounds right but I have never used
transactionSynctransaction
EI'm doing some local development with a durable object, is there a way to force an alarm to run/trick the date of the system so it runs?
LIn the vitest-integration-beta, there is
runDurableObjectAlarm()Also, I'm about to release @lumenize/alarms package modeled after Actor Alarms, with a few differences including built in support for testing. Docs still need work, but can be found here
EThanks - I was looking for something that would let me force some alarms / time travel, but I ended up adding a trigger locally and updating my DB so that I can setup the right pathways, then force it to work
LThat's the right instinct! It's why I added a testing trigger to Lumenize Alarms. TBH, I rarely use my 100x speedup alarm simulation since I added that.
EI've got a bit of a complex stripe subscription schedule setup, and needed to start a sub in future so that billing anchors etc are in the right place, so needed to trigger the future event to ensure that the alarm triggers the schedule build correctly
1Do DOs still have a 1MiB limit on outgoing WS messages? The limits page states that the new 32MB message limit is only for incoming messages
LDoes anyone have any experience with setting a zero delay alarm? I assume that they won't be skipped but that's one question. However, my real question is what's the delay between when you set the alarm and when it actually fires? Is it 1-2 ms? or can it be upwards of 10ms?
LIt can be upwards of 10ms for sure. You are not going to get a frequency at the single-double-digit milliseconds.
LI assume that awaiting a workers rpc call opens input/output gate? But how does not awaiting work? There might not be a fetch or message handler to finish to open them?
MIs calling
ctx.storage.deleteAll()Also, what round trip latency should I expect for Workers RPC calls. I'm seeing about 20ms?
LIf it's hibernated, the only thing it can do is wake up. But it will not disconnect clients. It will just delete storage.
1tbh I would have expected it to disconnect all clients, that's interesting
Ahas anyone here managed to get https://platform.openai.com/docs/guides/realtime-sip#monitor-call-events working in a worker/do? starting a new session works by either authing through subprotocols or using CloudflareRealtimeTransportLayer however, i can't for the life of me get it to work when hitting the wss://api.openai.com/v1/realtime?call_id={call_id} endpoint to connecting to an inflight call
1Are you calling the WSS URL in the DO or in Worker code? Are you just fetching, or creating a new WebSocket() object? I've had varied success using either solution with a few different WebSocket servers