Feature Flags API: React Polling and Defensive Defaults for Delivery Status

When presenting failed notification deliveries in a React support console, use a feature flags API as a polled configuration source. Ship a fallback configuration with the frontend, and keep sensitive decisions like delivery retry, billing, and authorization on the server. This approach is suitable for changing the presentation around delivery failures but not for real-time experimentation, audit history, or server-side policy enforcement.

The primary goal is to control how the customer-support UI displays failed notification deliveries, such as enabling a new failure-details panel or keeping the old summary view.

Treat the downloaded flag document as a cacheable hint, not as authority. Load defaults synchronously, render immediately, fetch current values asynchronously, and refresh them on a regular interval. If the request fails, retain the last known configuration. Never leave the console blank while waiting for configuration.

Two invariants apply: every flag must have a value before the network runs, and a refresh cannot weaken access checks or alter billing decisions. Choose a reasonable poll interval based on operational needs and document it. React components should consume the flag state through a single context to avoid starting multiple pollers. Keep the previous snapshot during refresh to avoid visual noise and screen jumps.

Do not embed general backend credentials in browser JavaScript. If the service requires a bearer key, authenticate it on your backend and expose only the non-sensitive flag values needed by the UI. The browser should poll this narrow same-origin response. This approach also allows the application team to apply response validation, cache headers, and request deadlines without burdening each React component with vendor-specific details.

A valid flag response schema should reject unknown types, rejecting a boolean fallback if replaced by a string just because the HTTP status was successful. Use a schema test against the discovery response and a fixture captured for the specific capability, and keep the fixture in the consumer's test suite. Shorter intervals increase request volume and make synchronized tabs more noticeable, while longer intervals increase exposure to stale presentation. Add random jitter around the chosen interval and ensure only one provider owns the timer per tab.

When failures occur, categorize them accordingly. A network timeout or malformed value is a configuration-refresh failure, not a notification-delivery failure. An HTTP 429 response indicates backpressure and should use Retry-After or exponential backoff. A closed laptop is not evidence of a healthy delivery pipeline. Cost attribution should attribute backend flag adapter requests to the support-console configuration workload, keeping notification sends, retries, and delivery telemetry in separate accounting categories.

Flag evaluations alone do not provide evaluation statistics, so exact per-agent or per-flag allocation would be speculative. If finance requires such breakdowns, this architecture may not be suitable without separate metering.