feat: Reduce streaming DNS failures with stale-fallback DNS cache by abelonogov-ld · Pull Request #323 · launchdarkly/android-client-sdk

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

abelonogov-ld · 2026-02-21T00:14:54Z

Summary

Add CachingDns, a thread-safe OkHttp Dns wrapper that caches successful lookups (10-min TTL) and returns stale cached addresses when a fresh resolution fails — preventing UnknownHostException from killing the stream during network transitions
Share a ConnectionPool and the DNS resolver across StreamingDataSource restarts (context switches, foreground/background toggles, network changes) via StreamingDataSourceBuilderImpl, so cached state survives data source recreation
Explicitly set retryOnConnectionFailure(true) on the streaming OkHttpClient on all API levels

Background

We observed a high percentage of DNS failures in streaming connections. The root cause is that StreamingDataSource creates a new OkHttpClient on every start() call, and ConnectivityManager restarts the data source on every network change — exactly when DNS is most fragile. OkHttp uses Dns.SYSTEM (InetAddress.getAllByName) with no caching, and Android's system DNS cache has very short TTLs (sometimes ~2 seconds) that get cleared on network transitions.

This pattern of application-level DNS caching with stale fallback is well-established: Alibaba's HTTPDNS SDK, gRPC-Java's DnsNameResolver, and Square's own DnsOverHttps module all implement similar approaches. Google validated the pattern by adding DnsOptions.StaleDnsOptions to the Android framework in API 34.

Test plan

Unit tests for CachingDns: fresh resolution, cache hits within TTL, TTL expiry refresh, stale fallback on failure, cold failure propagation, per-hostname isolation, expiration boundary
Existing StreamingDataSourceTest passes (builder creates data source with new constructor args transparently)
Verify via logs that CachingDns warns on stale fallback and that stream reconnects succeed during network changes

Note

Medium Risk
Touches streaming network connection setup and DNS resolution behavior; incorrect caching/pooling could cause connectivity regressions or use stale IPs longer than intended.

Overview
Adds CachingDns, an OkHttp Dns wrapper that caches successful lookups with a TTL and falls back to stale cached addresses when fresh resolution fails, reducing UnknownHostException disruptions during mobile network transitions.

Updates streaming to reuse a shared DNS resolver and ConnectionPool across StreamingDataSource restarts, and wires these into the EventSource OkHttp client configuration (including enabling retryOnConnectionFailure(true)). Includes unit tests covering cache hit/expiry behavior, stale fallback, per-host caching, and eviction behavior when exceeding MAX_ENTRIES.

^{Written by Cursor Bugbot for commit 0a6a23e. This will update automatically on new commits. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

… improved clarity and performance.

tanderson-ld

I think this needs more discussion in slack channel so we're on all the same page about possible impact and how we'll confirm there is no negative impact.

tanderson-ld · 2026-02-23T14:33:44Z

 clientBuilder.readTimeout(READ_TIMEOUT_MS, TimeUnit.MILLISECONDS);
+ clientBuilder.dns(dns);
+ clientBuilder.connectionPool(connectionPool);
+ clientBuilder.retryOnConnectionFailure(true);


The streaming data source already follows an exponential backoff at the event source layer. We shouldn't add more try logic as the exponential backoff was specified with agreement from flag delivery to have a known load in the case of cloud outage + recovery.

tanderson-ld · 2026-02-23T14:56:45Z

+
+ if (entry != null && !entry.isExpired(now)) {
+ return entry.addresses;
+ }


I think we should only use the cache in cases where the delegate fails to do lookup to minimize the impact of these changes on existing cases. My understanding of this PR is to handle a case that is not handled well today and not to improve the performance of caching in general.
Another reason is this cache has no other signals that can remove elements from it besides time, such as registered IP changes or VPN region change. It is feasible that a delegate could be aware of extra signals, but by using our own cache, we do not give the delegate an opportunity to use its possibly more complex behavior.

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

dns cache
f990e9e

abelonogov-ld requested a review from a team as a code owner February 21, 2026 00:14

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java
Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

abelonogov-ld added 2 commits February 20, 2026 16:19

cap cache
1cd1904

fix modifiable issue
ebd37ab

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/CachingDns.java

Make cache for all
4c65601

cursorBot reviewed Feb 21, 2026
View reviewed changes

Comment threadlaunchdarkly-android-client-sdk/src/main/java/com/launchdarkly/sdk/android/ComponentsImpl.java

abelonogov-ld added 2 commits February 20, 2026 16:29

fix eviction logic
443c6b3

Refactor eviction logic in CachingDns to use an explicit iterator for…
0a6a23e
… improved clarity and performance.

abelonogov-ld changed the title ~~feat: Reduce streaming DNS failures with stale-fallback DNS cache (API < 34) Body:~~feat: Reduce streaming DNS failures with stale-fallback DNS cacheFeb 21, 2026

tanderson-ld reviewed Feb 23, 2026
View reviewed changes

abelonogov-ld marked this pull request as draft June 3, 2026 17:40

Uh oh!

Conversation

abelonogov-ld commented Feb 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Background

Test plan

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tanderson-ld left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

abelonogov-ld commented Feb 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Background

Test plan

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tanderson-ld left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

abelonogov-ld commented Feb 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Background

Test plan

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tanderson-ld left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

abelonogov-ld commented Feb 21, 2026•
edited
Loading

tanderson-ld left a comment •
edited
Loading

abelonogov-ld commented Feb 21, 2026•
edited
Loading

tanderson-ld left a comment •
edited
Loading

abelonogov-ld commented Feb 21, 2026•
edited
Loading

tanderson-ld left a comment •
edited
Loading

abelonogov-ld commented Feb 21, 2026•
edited
Loading

tanderson-ld left a comment •
edited
Loading