ref(core): Measure the hostname cache TTL on a monotonic ticker (JAVA-579)

[runningcode]

📜 Description

HostnameCache stored an absolute expiry built from System.currentTimeMillis() and compared it against a fresh reading of the same clock:

expirationTimestamp = System.currentTimeMillis() + cacheDuration;
// ...
if (expirationTimestamp < System.currentTimeMillis() && ...) { updateCache(); }

A device time change therefore resized the 5 hour TTL. A backward step extended it by the size of the step; a forward step expired the cache early. Now a Deadline on a MonotonicTicker, so the TTL is the interval it claims to be.

The expiry field also no longer starts at 0. On a boot-relative ticker 0 is a real and very recent instant, so a field left at 0 reads as freshly set rather than as unset — it now starts as Deadline.passed(ticker), so nothing counts as cached before the first resolve.

The TTL is not a serialized value — it only decides when the SDK re-resolves the hostname — so this is not gated behind the v9 work.

💡 Motivation and Context

Audit finding §C6 from the clock-usage audit, which lists four wall-clock TTL/cleanup sites. This is one of them. See "Next steps" for where the other three went.

• resolves: JAVA-579 (partially — the HostnameCache TTL only)
• part of: Remaining low-priority clock issues and clock-step regression coverage #5582

💚 How did you test it?

New test in HostnameCacheTest: the hostname is re-resolved once the cache duration has elapsed, and not before, driven by advancing a TestMonotonicTicker rather than by sleeping for five hours. This path had no test at all previously — it was not reachable without a real clock.

MainEventProcessorTest, the other HostnameCache consumer, passes unchanged (45 tests).

📝 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.

The package-private constructor gained a MonotonicTicker parameter, which is what makes the TTL testable. The existing HostnameCache(long, Callable<InetAddress>) overload is unchanged, so existing callers and tests are unaffected.

🔮 Next steps

The rest of §C6:

• The 30 second performance-collection budget is the same class of bug and is fixed separately in the companion PR.
• The other two sites — profiling-trace cleanup in Sentry.java and envelope rotation in CacheStrategy — both compare against File.lastModified(). A filesystem mtime is a wall-clock value, written by another process at a moment we never observed, so there is no monotonic quantity to compare it against; moving either to a ticker is not possible. Fixing them properly means not relying on mtimes at all (recording our own timestamp beside each file), which is a storage-format change well outside this item.
• §C6 also mentions the 100ms sampling loop running on java.util.Timer. That is a scheduling change rather than a TTL one and needs its own PR.

🤖 Generated with Claude Code

[linear-code]

JAVA-579

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings