# Emulating Relay Proxy issues This topic explains how to test application behavior when the Relay Proxy is down or unreachable. This page covers two situations: 1. No prior connection to LaunchDarkly to create the cache or populate the persistent data store 2. The Relay Proxy already running with cache or persistent data store populated, then disconnected ## Cold relay A **cold relay** scenario covers the Relay Proxy starting when it cannot reach LaunchDarkly, or when your application targets a Relay Proxy that is not reachable during startup. ### Point SDK URIs at an unreachable host Follow the same approach as invalid endpoint tests for direct LaunchDarkly connections. Configure streaming, base, and polling URIs in the SDK so they target a host that accepts no connections instead of your Relay Proxy endpoint. This path also exercises the case where the Relay Proxy is unreachable inside a customer's own network while an application attempts to connect to it. The customer should verify proper alerting is triggered in their system during the cold relay test. Read [Init and Config](../sdk/preflight-checklist/init-and-config.md) for baseline SDK timeout and initialization guidance. ### Misconfigure the Relay Proxy streaming URI Deploy a Relay Proxy configuration that sets `streamUri` in the `[Main]` section to an endpoint that never accepts a connection. Set `ignoreConnectionErrors` to true so the process keeps running. Tune `initTimeout` to the wait you expect before the Relay Proxy serves from a persistent store when you use one. This example shows the pattern: ```ini [Main] streamUri = "http://127.0.0.1:1" ignoreConnectionErrors = true initTimeout = 10s ``` You must still define the rest of the Relay Proxy configuration, the above is a snippet. ## Warm relay A **warm relay** scenario covers a Relay Proxy that already initialized against LaunchDarkly and is serving from its in-memory cache or from a persistent data store. Complete these steps: 1. Start the Relay Proxy with a normal configuration. Let it initialize and write flags to the persistent store when you use one. 2. Block the LaunchDarkly streaming connection while the Relay Proxy keeps running. Use a firewall rule, a network partition, or the methods in [Emulating LaunchDarkly Downtime](../cookbook/testing/emulate-downtime/index.md). 3. Start your application with SDK URIs pointed at the Relay Proxy. 4. Verify the application reads real flag values from the Relay Proxy or its store. Confirm it does not rely solely on hardcoded fallback values in code. If the Relay Proxy is misconfigured, behavior may be different than expected. ## Observe connection state during tests Use the Relay Proxy `/status` endpoint to inspect connection health during a test. The endpoint returns JSON. Do not treat HTTP 200 alone as proof that the Relay Proxy is healthy. Parse the JSON and read the reported fields. The `disconnectedStatusTime` setting in `[Main]` controls how long a stream may stay interrupted before the status reflects a full disconnect. Read [Proxy Mode](./proxy-mode.md) for details. The /status endpoint returns JSON: - While LaunchDarkly streaming works, you see `"status": "connected"` and `"connectionStatus": { "state": "VALID" }`. - Right after you block the stream, and before `disconnectedStatusTime` elapses, you see `"connectionStatus": { "state": "INTERRUPTED" }`. The top-level `"status"` can still be `"connected"` during that window. - After `disconnectedStatusTime` elapses, you see `"status": "disconnected"` and an overall **degraded** condition in the status payload. ## Testing Frequency Run Relay Proxy issue testing on a less frequent cadence such as in a full regression suite during a disaster recovery exercise. ## Related topics - [LD Relay overview](./index.md) - [Using LD Relay](../resilency/ld-relay.md)
Last modifiedLast reviewedReview due
Last commit: 2e92061