We are currently exploring the implementation of feature flags via streaming in our application using GrowthBook, and I have some questions regarding the retry logic for sending feature flag updates that I couldn't find answers to in the documentation. Specifically, I am interested in understanding how GrowthBook handles the following scenarios: 1. Connection Drops: In the event of a dropped connection, what is the process for re-establishing the connection? As I understand the connection is restored on a client client side (standard SSE behaviour) but how GB handle this on the server side. 2. Timeouts During Updates: When there is a timeout while GrowthBook attempts to send an update to a client, what steps are taken to ensure the update is eventually delivered? Is there a specific retry mechanism in place for such situations? Additionally, I have a few more related questions : • Error Handling: How does GrowthBook handle errors that occur during the streaming of feature flag updates? Are there specific error codes or statuses that we should be aware of and handle on our end? • Client-Side Handling: What best practices does GrowthBook recommend for client-side handling of streaming connections, especially in terms of maintaining connection stability and handling potential disconnections or timeouts? • Monitoring and Logging: Does GrowthBook provide any tools or logs that can help monitor the status of streaming connections and troubleshoot issues related to feature flag updates delivery.

It's best to think of SSE updates as "nice to have" instead of relying on their delivery. There is no retry/integrity checking in place, it's a blind multi-client broadcast. If you require updating on an interval with proper retry/error handling, you'd probably need to build in your own refetch logic at the SDK implementation level (although be careful, this can greatly increase your API traffic...)

Do you plan to introduce any "retry" mechanism at some point?

Are you on Cloud or self-hosted? On cloud, we don't have any specific plans around this because it's less efficient from a network traffic standpoint (forces a bit of per-user statefulness around what would otherwise be a 1-way fanned out broadcast). For self hosted streaming connections through the GB Proxy, we could consider adding some form of this to the roadmap.

we are in the Cloud at the moment