fix(android): Treat an unpopulated connection cache as stale (JAVA-717) by runningcode · Pull Request #6029 · getsentry/sentry-java

runningcode · 2026-08-31T15:25:07Z

PR Stack (Clock semantics hardening)

📜 Description

AndroidConnectionStatusProvider used 0 to mean "cache never populated", and compared it against SystemClock.uptimeMillis():

private volatile long lastCacheUpdateTime = 0;
private static final long CACHE_TTL_MS = 2 * 60 * 1000L;

private boolean isCacheValid() {
  return (timeProvider.getCurrentTimeMillis() - lastCacheUpdateTime) < CACHE_TTL_MS;
}

uptimeMillis() is 0 at boot, so 0 does not mean "unset" — it means "populated at boot". For the first two minutes of every boot, an empty cache reads as fresh.

The cache now holds a Deadline, so "never populated" is expired by construction and has no numeric value to get wrong.

Stacked on #6028, which adds the clock types this uses.

💡 Motivation and Context

resolves: JAVA-717

💚 How did you test it?

A regression test asserts that a provider constructed at tick 0 populates the cache before reading it. It fails if the deadline is constructed fresh instead of passed, which is the shape of the original bug.

📝 Checklist

I added GH Issue ID & Linear ID
I added tests to verify the changes.
No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
I updated the docs if needed.
I updated the wizard if needed.
Review from the native team if needed.
No breaking change or entry added to the changelog.
No breaking change for hybrid SDKs or communicated to hybrid SDKs.
Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

linear-code · 2026-08-31T15:25:11Z

JAVA-717

sentry · 2026-08-31T15:29:58Z

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.55.0 (1)	release

⚙️ sentry-android Build Distribution Settings

`When network is active but not connected with permission, return DISCONNECTED` mocked an active network reporting isConnected=false alongside NetworkCapabilities describing a validated WiFi link. Those describe opposite worlds. It passes today only because the empty connection cache reads as fresh for the first two minutes of every boot (JAVA-717), which forces the legacy activeNetworkInfo path where the capability mocks are never consulted. buildInfo reports API 24, so once that bug is fixed the provider reads capabilities and the test would fail for a reason that has nothing to do with what it is named after. Fixing the mocks first keeps that failure from being buried in the commit that fixes the cache. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

lastCacheUpdateTime used 0 for "never populated" while being compared against SystemClock.uptimeMillis(), which starts at 0 at boot. For the first two minutes of every boot the empty cache therefore read as fresh, so getConnectionStatus() skipped updateCache() and fell through to the legacy activeNetworkInfo path instead of reading NetworkCapabilities. The window reopens after every unregisterNetworkCallback(), which reset the field to 0. Switching clocks does not fix this on its own: elapsedRealtimeNanos() also starts at 0 at boot. Any 0-means-unset long compared against a boot-relative clock has the same flaw; only epoch millis made it safe, because there 0 is 1970. The cache now holds a Deadline, so "never populated" is expired by construction and has no numeric value to get wrong. The provider takes an MonotonicClock in place of ICurrentDateProvider, which is what a two-minute TTL wants: it must keep counting while the device sleeps. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

0xadam-brown

A couple quick comments if you want them; no blockers.

0xadam-brown · 2026-09-08T13:48:44Z

                cachedNetworkCapabilities = null;
                currentNetwork = null;
-                lastCacheUpdateTime = timeProvider.getCurrentTimeMillis();
+                cacheFreshUntil = Deadline.after(ticker, CACHE_TTL_MINUTES, TimeUnit.MINUTES);


Seeing this in action, I wonder if there isn't a better name than Deadline.after()? ("after" makes me think that perhaps we're offsetting the start of the deadline until the time we pass to after())

Thoughts about until()? I prefer it b/c my mind defaults to thinking that whatever I'm returned is "valid"; a deadline that's passed isn't; and until() points to the valid time segment.

(I also considered at(), which reads nicely here, but (I think) mostly because my mind is sneaking in the idea of a clock, and not reading this as a pure duration.)

Happy to defer to you...

0xadam-brown · 2026-09-08T13:48:55Z


  private boolean isCacheValid() {
-    return (timeProvider.getCurrentTimeMillis() - lastCacheUpdateTime) < CACHE_TTL_MS;
+    return !cacheFreshUntil.hasPassed();


l: We could add a hasNotPassed() method to Deadline, as well. I bet it'll get a lot of use.

This was referenced Aug 31, 2026

ref(transport): Measure rate-limit backoff on a monotonic clock (JAVA-574) #6030

Draft

ref(checkin): Measure check-in durations with Stopwatch (JAVA-576) #6032

Draft

feat(time): Add a monotonic clock abstraction (JAVA-571) #6028

Open

runningcode force-pushed the no/java-571-clock-abstractions branch from 2d9f213 to c2f7b51 Compare September 2, 2026 08:23

runningcode force-pushed the no/java-717-connection-cache-deadline branch from 00b4937 to 7eae6db Compare September 2, 2026 08:23

This was referenced Sep 2, 2026

ref(android): Measure ANR thresholds on the monotonic clock (JAVA-579) #6041

Draft

ref(time): Deprecate the legacy date and clock providers (JAVA-571) #6043

Draft

feat(time): Add Timestamp, EpochClock and AnchoredClock (JAVA-572) #6045

Open

runningcode force-pushed the no/java-717-connection-cache-deadline branch from 7eae6db to e20e3fa Compare September 2, 2026 13:35

runningcode changed the base branch from no/java-571-clock-abstractions to no/java-572-timestamp-timing September 2, 2026 13:35

runningcode force-pushed the no/java-717-connection-cache-deadline branch from e20e3fa to 2b35532 Compare September 2, 2026 13:37

runningcode force-pushed the no/java-572-timestamp-timing branch from aa53f2e to 7255d5e Compare September 3, 2026 15:11

runningcode force-pushed the no/java-717-connection-cache-deadline branch from 2b35532 to 76fef57 Compare September 3, 2026 15:11

runningcode force-pushed the no/java-572-timestamp-timing branch from 7255d5e to a372da0 Compare September 3, 2026 15:41

runningcode force-pushed the no/java-717-connection-cache-deadline branch from 76fef57 to 81e7109 Compare September 3, 2026 15:41

runningcode force-pushed the no/java-572-timestamp-timing branch 2 times, most recently from bec70fb to 686cc80 Compare September 4, 2026 08:29

runningcode force-pushed the no/java-717-connection-cache-deadline branch from 81e7109 to 47bf886 Compare September 4, 2026 08:30

runningcode mentioned this pull request Sep 4, 2026

[DO NOT MERGE] feat(time): Anchor span timestamps on one wall-clock reading (JAVA-572) #6055

Draft

runningcode marked this pull request as ready for review September 4, 2026 14:45

runningcode requested review from 0xadam-brown, adinauer, markushi and romtsn as code owners September 4, 2026 14:45

runningcode added the sanity-check PR needs a lightweight review for obvious issues label Sep 4, 2026

runningcode force-pushed the no/java-572-timestamp-timing branch from 686cc80 to 655adfb Compare September 4, 2026 15:11

runningcode force-pushed the no/java-717-connection-cache-deadline branch from 47bf886 to c45669e Compare September 4, 2026 15:11

runningcode force-pushed the no/java-572-timestamp-timing branch from 655adfb to 0969abb Compare September 8, 2026 13:22

runningcode and others added 3 commits September 8, 2026 15:22

Add changelog entry for JAVA-717

0154972

runningcode force-pushed the no/java-717-connection-cache-deadline branch from c45669e to 0154972 Compare September 8, 2026 13:24

0xadam-brown approved these changes Sep 8, 2026

View reviewed changes

Navigation Menu

Uh oh!

Uh oh!

fix(android): Treat an unpopulated connection cache as stale (JAVA-717) - #6029

fix(android): Treat an unpopulated connection cache as stale (JAVA-717)#6029
runningcode wants to merge 3 commits into
no/java-572-timestamp-timingfrom
no/java-717-connection-cache-deadline

runningcode commented Aug 31, 2026 •

edited

Loading

Uh oh!

linear-code Bot commented Aug 31, 2026

Uh oh!

sentry Bot commented Aug 31, 2026 •

edited

Loading

Uh oh!

0xadam-brown left a comment

Uh oh!

0xadam-brown Sep 8, 2026

Uh oh!

0xadam-brown Sep 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

runningcode commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Stack (Clock semantics hardening)

📜 Description

💡 Motivation and Context

💚 How did you test it?

📝 Checklist

Uh oh!

linear-code Bot commented Aug 31, 2026

Uh oh!

sentry Bot commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📲 Install Builds

Android

Uh oh!

0xadam-brown left a comment

Choose a reason for hiding this comment

Uh oh!

0xadam-brown Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

0xadam-brown Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

runningcode commented Aug 31, 2026 •

edited

Loading

sentry Bot commented Aug 31, 2026 •

edited

Loading