You can use the CF API to invalidate the cache which from their blog a while ago is a few seconds to purge globally. But KV's cache you cannot purge (afaik) it will be up to 60s

Does that work for cache API called in workers too?

What serialisation scheme and/or database does durable objects use behind the scenes for the storage API?

The V8 Clone/Serialization algorithm

yeah it should work fine

Hey there, is there any way to send protocol level Websocket ping-pong frames from Durable Objects. (I guess this is more of a CF Websocket question rather than a Durable Object one but I couldn't find the proper place to ask it).

how many bytes long is the DO random ID? 32?

Pretty sure all DO ids are 64 characters

yah so as hex that's 32 bytes, ty!

Hmm, this is a new one - just got this one in production

Too many API requests by single worker invocation

What does that mean exactly?

How many requests are you doing?

many, everywhere, all the time

I'd assume the limits of 1k requests are the same for DOs as they are for kv/r2/etc

I think this is in an eyeball worker, making DO calls

also could be downstream DO to DO

"API" is a little vague for me - I'd like to know exactly which limit is being hit here - seems back to normal now, with no real traffic difference

I don't see the string in

workerd

But the string is in the Miniflare repo, with an additional suffix that the production error message does not have:

1000 KV and Durable Object requests per invocation

Yeah thats what I thought it would be

so might be the 1000 do calls, maybe

i don't do kv in this path

anyway would be awesome for someone orange to eventually confirm where that error msg is in the production runtime, thanks! we need an open source production error message list

As an example: does 1000 DO requests: just fine : does 1001 DO requests: the error

ooh nice!

caught in the act

All bindings have the 1k limit but it is separate (or at least should be).

thanks!

i will have to un ddos myself somewhere

queues GA cannot come quickly enough

We have been seeing exceptions without error messages from within a durable object constructor when it is initialized from an alarm since Thursday or Friday last week. In the constructor, a new alarm has been scheduled within the state.blockConcurrencyWhile call. We were able to resolve these exceptions by checking if an alarm is already set before scheduling a new one. The problem was not clear, as the exceptions could not be caught and did not show any message in the log tail.