## Overview The feature flag client must have an aggressive timeout configured on all HTTP requests to the feature flag service. Without strict timeouts, slow or unresponsive feature flag service calls risk hanging indefinitely, blocking production critical paths and degrading overall system reliability. ## Motivation Feature flag evaluation sits in the critical path of many requests. If the HTTP client used to communicate with the feature flag service does not enforce tight timeouts: - **Hanging requests** can exhaust connection pools and goroutine/thread resources - **Cascading failures** can propagate from the feature flag service to the main application - **Latency spikes** can degrade user-facing response times - **Production incidents** can result from what should be a non-critical, best-effort operation An aggressive timeout ensures that feature flag lookups fail fast and fall back gracefully, protecting the production critical path. ## Scope - Audit the current HTTP client configuration used by the feature flag client - Define and enforce an aggressive request timeout (connection timeout, response header timeout, and overall request timeout) - Ensure timeouts are configurable but default to appropriately low values - Validate that on timeout, the client fails gracefully and falls back to the default flag value - Add observability (metrics/logs) for timeout events to aid in monitoring and tuning ## Acceptance Criteria - [x] The feature flag HTTP client has an explicit, aggressive timeout configured for all requests - [x] Timeout values are configurable and documented, with sensible low defaults - [x] On timeout, the client returns the default/fallback flag value without propagating an error to the caller - [x] Timeout events are observable via logs or metrics - [x] Behaviour is validated under simulated slow/unresponsive feature flag service conditions - [x] No hanging requests are possible that could impact production critical paths ## Implementation Implemented in [gitlab-org/labkit](https://gitlab.com/gitlab-org/labkit): - `defaultHTTPClientTimeout = 2 * time.Second` — aggressive default applied unconditionally (`v2/featureflag/client.go`) - `Config.HTTPClient` — fully configurable, documented with override example - Graceful fallback — both `BooleanValueDetails` and `StringValueDetails` return the default value on any error - OTel span records errors (including timeouts) when a tracer is configured - `http.Client.Timeout` covers the full round-trip; hanging is impossible - Integration tests with a hung `httptest.Server` — merged in [labkit!495](https://gitlab.com/gitlab-org/labkit/-/merge_requests/495) ## Related - Epic: [&376](https://gitlab.com/groups/gitlab-org/quality/-/work_items/376) - Post-Deployment DevEx Support for Artifact Registry