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 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:
[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:
- Start the Relay Proxy with a normal configuration. Let it initialize and write flags to the persistent store when you use one.
- 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.
- Start your application with SDK URIs pointed at the Relay Proxy.
- 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 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
disconnectedStatusTimeelapses, you see"connectionStatus": { "state": "INTERRUPTED" }. The top-level"status"can still be"connected"during that window. - After
disconnectedStatusTimeelapses, 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.