We have more work to expose KV data as read-only. Good to know there's a want here
We have more work to expose KV data as read-only. Good to know there's a want here
PIs there any publicly available benchmarks on durable object size vs startup time? I'm storing a lot of data in durable objects transiently (~30gb, will be sharded over multiple obviously), and latency is a concern. Sharding isn't a big deal, but I don't want to pre-emptively overshard for no reason.
XThis looks awesome. Is the setup for using this in a multi-worker situation the same as with the vitest integration? (Precompile typescript to JS and then manually configure the secondary workers with miniflare?)
1I would totally use this too
1So I realised that this behaviour with CORS in the SDK isn't documented anywhere in the docs except for the changelog where it was introduced
LThat's one of the problems with . The team has traditionally not consider docs (or quality, responsiveness on Discord, etc.) important although they say they are working on improving them. Also, it must be said that they have always had a great API design, even if you have to crawl in the code to discern it.
I have crawled around in their code and my docs on how CORS behavior works default and allow everything, are accurate for routeAgentRequest but I recommend strongly against using if you are using WebSockets. They don't support the whitelist or custom validation function modes that mine does.
I have crawled around in their code and my docs on how CORS behavior works default and allow everything, are accurate for routeAgentRequest but I recommend strongly against using if you are using WebSockets. They don't support the whitelist or custom validation function modes that mine does.
EHas anyone successfully been able to use Sandbox? https://sandbox.cloudflare.com/
Been up all night.
Issue: Sandbox Sandbox SDK returning placeholder mode despite correct configuration
"Agent provisioned in placeholder mode (Cloudflare Sandbox API not configured)."
When my worker calls Sandbox.create it falls back to “placeholder mode” because the binding isn’t populated (runtime logs show Agent provisioned in placeholder mode (Cloudflare Sandbox API not configured)). It looks like Containers access hasn’t been enabled on my account yet.
Been up all night.
Issue: Sandbox Sandbox SDK returning placeholder mode despite correct configuration
"Agent provisioned in placeholder mode (Cloudflare Sandbox API not configured)."
When my worker calls Sandbox.create it falls back to “placeholder mode” because the binding isn’t populated (runtime logs show Agent provisioned in placeholder mode (Cloudflare Sandbox API not configured)). It looks like Containers access hasn’t been enabled on my account yet.
SPlease do not post your question in multiple channels/post it multiple times per the rules at #
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.
J
i noticed that errors thrown from functions called across a workers RPC boundary don't contain the original stack trace (for example when calling a function on a durable object stub or a service binding)the serialized error that crosses the RPC boundary only contains the error message but not the stack
i'd really like to retain the original stack trace. what's a good pattern for doing that? stuff the stack trace in the message? or could i throw a custom error with the stack trace serialized in a property? would that cross the RPC boundary?
and is there a place where i can intercept any errors thrown out of the RPC boundary from the callee's side?
NI'm working on an app where I use DO per user model. Given the release of data studio, allowing the inspection of a DO's SQLite storage, is there a way to assure users that I CAN'T inspect the state of their DO's state? Basically, can I limit access to data studio?
Gclient side encryption
Geven then since you control the code you could still snoop
VHi, any decent approach or documentation how to make sure or what guarantees a DO instance won’t hibernate while there is a logical task executing (in most cases involving IO)? Some clarity on this topic would help me design system properly. Currently hacking via repeated alarms , reminds me old times Android keep awake hacks. Not good.
LIt shouldn't hibernate when you are awaiting external fetch (what I assume you mean by "IO"). The limit on CPU usage defaults to 30 seconds but that clock doesn't run when you are only waiting on an external fetch. Also, it can be bumped up to 5 minutes.
1I have a bunch of DO namespaces I want to convert from KV to SQL backend, is the official migration process coming soon or should I just create new namespaces and migrate data?
VClock time you are referring to is worker cpu time limit?
Gyou finally making the jump?
1Yeah I'm in quiet season at work so I finally have time to dedicate to re-architecting everything
Li believe so
LThere isn't an ETA yet, so if you need it now, I suggest doing the migration of the data yourself for now.
1No worries appreciate the clarity. I'll use it as an opportunity to rewrite everything while I'm at it, there's been plenty of changes I can take advantage of since I first built it all
LI probably shouldn't have used the word "clock". It's confusing. DOs are billed on wall clock time. However, their run length limits are CPU clock time which is an order of magnitude or two more generous when you have external fetches involved. It wouldn't surprise me if it were able to wait on a fetch for 20 minutes. You'll pay for the DO the whole time, but it would still use less than 30 seconds of CPU.
1If I delete a DO's storage, let it evict then request the same instance, will it always spawn in the same colo? I've gotten an instance in Perth which I'd really love to move closer to home
PIf it's being spawned off of a request, it's usually pretty sticky from my experience, but if you specify a location hint instead I've had more success with it sometimes moving to a different datacenter. Not quite sure what the spawn algorithm is because it's seemingly slightly different each time I try.
For what it's worth, when I want a DO instance near a specific point, this is pretty inefficient but I just have a worker spawn and destroy DO instances with a region hint and with slightly different names then returns the name/id of the one in the POP I want
For what it's worth, when I want a DO instance near a specific point, this is pretty inefficient but I just have a worker spawn and destroy DO instances with a region hint and with slightly different names then returns the name/id of the one in the POP I want
PThis is in ENAM though, so I don't know how it is in other regions
1The locations I wanna use are within the same location hint, the routing just seems to really suck in this case (going from side of Australia to the other can be awful in terms of routing). I also don't really wanna have to stray away from the current name I am using for this instance
PHonestly, I'd just spin a quick test worker to spin and destroy a DO like 10 times with the same name with a set location hint. YMMV but usually thats enough to get a couple of different POPs. If that works, then just do that again with the DO class and name you want until it's in the right region then use it
1I like it thank you
Pnp and please let me know how it goes. I haven't experimented with coercing DOs to specific POPs outside of ENAM/WNAM and would love to know if that hack works elsewhere lol
PMy old trick was to spin a lambda instance in a nearby AWS center and hit the endpoint...
1Its never been a problem before, normally get them always in Melbourne which is close to home. There's only a 33% chance a DO will spawn in Perth via Melb instead of Sydney so I just got unlucky with this one. I will test out hitting the same instance and see how I go
PThat makes sense. I'm working on a small tool that I'll need to put small DOs in very specific areas (one of which is in Australia) so I've been playing around more and more with forcing the DO placement algo where I want lol. I kinda wish CF could just let me specify the IATA code of where I want it, but I'm guessing there are architecture limitations there
1So to confuse myself more, I just requested a new instance (first one was named '2025', this one is '2026') and it ended up in the same colo but with far better response times when hot?? Def need to test this out more
1These instances are also entirely fresh with no data stored beyond the runtime-abstracted stuff
IAs far as I remember, yes.
12025 gives me around 350ms when hot, 2026 gives me around 150ms which is not insignificant. Both in Perth
PHow are you measuring the colo it's running in?
1Just from the CF logs
IIn fact if I remember correctly once you create a DO with a specific name it's always in that colo even if you delete, evict, and recreate a while later (not 100% but that's what I remember).
PInteresting
PThat's also pretty annoying
PMy habit of completely not caring about my DO names and making them random numbers or UUIDs comes in handy once again!
1Its just annoying cos I have a bunch of data that I want to associate to a specific year, I can rearchitect around it but would rather not
IIf you do this I highly recommend using newUniqueId() rather than idFromName() if you can, it saves a round trip
PI've had this happen before, and I genuinely have no idea what causes it. Maybe different machines or something? But also usually for me when it happens, sometimes when its recreated out of idle later the latency changes again
1I'll wait a bit and see if I get similar results
POh interesting, I didn't know that. Thanks for the tip!
Prn my scheme is usually [IATA of incoming request worker]-[DO type/name]-[some sort of short random number or UUID] so that in logs it shows up a little nicely, but I think I'm just going to go full IDs now
IYeah basically if you use the the runtime has to check (globally) whether the DO exists already whereas if you do it's generated in a way that it will always be unique and doesn't need to do that double-check