Hi again, We recently launched a feature with a large saved group (10k records) and noticed that the number of configuration retrieval errors doubled. After we disabled the feature, the errors started to decrease. Could you please let me know if this is somehow related to the SDK, or if we need to investigate the issue on our end? Our setup is as follows: Growthbook -> Growthbook Proxy -> Cloudflare -> App.

Hi We’ll investigate this and follow up with you.

Hi, @late-ambulance-66508. We've investigated the issue and here's what we found. Root cause When a regular Saved Group is attached to a feature, GrowthBook embeds the full list of IDs into every /api/features/ response. With 10k records, the payload becomes too large and gets rejected somewhere in your Cloudflare -> Proxy chain, causing the failedToFetchData errors to spike. What you need to do Switch the saved group to Large List type in GrowthBook (Data & Metrics -> Saved Groups). Large Lists are evaluated server-side by GrowthBook Proxy and are never sent to the client, so the payload size stays the same regardless of how many members the group has. Since you already have GrowthBook Proxy in your setup, no additional configuration is needed. Bugs we found and fixed in the SDK While investigating, we identified two additional issues triggered by this scenario: 1. When a network request failed and the SDK successfully fell back to cached data, the refreshHandler was still reporting an error - so the app showed an error state even though features were working fine from cache. 2. The original network error (e.g. timeout) was being swallowed, making it impossible to diagnose the actual cause from the client side. Both fixes are included in the upcoming SDK release.

Hi @calm-dog-24239 Thanks! What do you mean by Large List type? I see only

ID lists

there

Please let us check that

We have

Pass Saved Groups by reference

option, but as I checked the payload, it also includes all lists there, but makes it available for multiple features

Pass Saved Groups by reference — unfortunately, enabling this option doesn’t solve the issue in this case, because the payload still contains the entire expanded list of members. The only effective workaround is either: • switching to a Condition-type group, or • resolving the group membership server-side instead of sending the full list in the request. Regarding the error category split, this has already been addressed in the upcoming SDK update. The

failedToFetchData

code will remain the top-level classification, but the SDK will now preserve the original network error details in

error.underlying

. This means you'll be able to reliably distinguish between: • request timeouts, • HTTP 5xx responses, • connection failures, • and other transport-level issues by inspecting

error.underlying

.

what's the payload size that's getting rejected? where do you see these payload drops?

@freezing-postman-69602 ~ 350 KB, But this doesn’t happen all the time, and it affects only a small percentage of users. Still, when rolling out a single feature can break other critical business logic, that’s not good. Maybe we should move large lists to a separate endpoint and load them independently of the main rules? I realize that this would need to be implemented on the backend first, but it seems like a more fault-tolerant solution.

that's weird. There are no preset limits on the size of payload and 350KB from Cloudflare shouldn't be an issue. Have you tried linked Saved Groups and see if it helps?

I'll give it a try next time we need long lists. I think it's because our app can be used by people with poor internet connections. The fact that this happens to a small number of users partly confirms this.