Hey everyone, bit of a particular question. We're running a pretty complex pipeline with Cloudflare workers and a Next.js app. We're calling Growthbook

init

in multiple places - starting with the cloudflare workers. Then also in the Next.js middleware and finally in the Next.js browser-side (not all at the same time, of course). We've been monitoring the app behaviour and noticed that quite a few times the

init

call fails with a timeout, even if it's been set to 2000ms which is quite high already. Is there a way to know: • Why it's happening, or have more info than just what's described here? https://docs.growthbook.io/lib/js#error-handling • Can we do something about these timeouts or is it completely out of our control? We're using the cloud based service, not self-hosting We're seeing around 0.5% timeouts over successful inits (network/cache), so not a huge issue, but would still be good to know why this happens. To give you an idea of the traffic, we have around 2m unique visitors per month. Thanks!

@happy-autumn-40938 can you help when you're around?

Hi Nicolaos, are you noticing the failure rate more prominently in a specific environment? For example, observing browser-side failures would be more common than backend (unless you're doing SDK payload hydration)

Hi @happy-autumn-40938 interestingly with the same sample rate on both our browser and backend we're seeing more failures in the backend - the backend being the cloudflare worker. The main difference being that in the worker we have a 2s timeout on the

init

whereas on the browser we kept the defaults - not sure what the timeout default is in that case?

That's odd... Are you using a key/val store + SDK webhooks to store and hydrate the payload within CloudFlare? Doing this might remove the timeout altogether in the worker. https://docs.growthbook.io/lib/edge/cloudflare#payload-caching-with-cloudflare-kv-store

We’re using the KV store with the local storage polyfill from the GB edge package, I assume that the initialisation from cache (via the KV store) does not timeout, but probably when the attempt is on the network that’s when it fails. Is there a way to confirm this? As I said, the failure rate is rather minimal but it’s still not very clear why it fails. We’re not using the webhooks, just calling growthbook.init and relying on GB to make the network call if needed

I don't have a good sense of where the delta is coming from. You could try monkeypatching the fetch call if you wanted to do a bit more debugging. But I'd look into implementing the webhook -> KV solution first, since it should eliminate all edge-side SDK payload fetches.

Thanks for the suggestion @happy-autumn-40938 - currently implementing that and will let you know how it goes. I have an issue though, not sure if it's a bug or if i misunderstood the doc, but we have two SDK connections: • development • production I added the KV store webhook to development, and i see there's a 1 webhook limit per connection for the free plan (we're on the legacy plan). When i go to add it to the

production

environment, the button to add the webhook is enabled but then i get a 400 error with:

{
  "status": 400,
  "message": "your webhook limit has been reached",
  "errorId": "e0f800fa7ac54e0ab966baee2941555d"
}

Could you let me know if this is normal? thanks

Sorry about the delay. It looks like the limit is working as intended; there is a 1 webhook per organization limit for free accounts. We'll have a look at improving the UI to make this more clear.

Ah that’s a shame, so in this case we would only be able to use the webhook for prod, and rely on the memory polyfill for other sdk connections ?

Yeah that sounds about right. If it makes things cleaner for you, there is no harm in keeping the polyfill around for your production worker as well (it's just redundant caching)