ref(core): Measure the performance-collection budget on a monotonic ticker (JAVA-579)

[runningcode]

📜 Description

DefaultCompositePerformanceCollector decided a transaction had been collecting for 30 seconds by subtracting two options.getDateProvider() readings:

this.startTimestamp = options.getDateProvider().now().nanoTimestamp();
// ...
return transaction != null
    && nowNanos > startTimestamp + TimeUnit.MILLISECONDS.toNanos(TRANSACTION_COLLECTION_TIMEOUT_MILLIS);

Those readings are wall-clock on every platform, including Android. It looks like it might be monotonic because SentryNanotimeDate carries a System.nanoTime() component, but nanoTimestamp() returns DateUtils.millisToNanos(unixDateMillis) — the nanoTime component is only used by diff(), which this code does not call. So the extra precision that type exists for never entered this comparison, and a device time change either ended collection early or kept it running well past the budget.

Each CompositeData now holds a Deadline on a MonotonicTicker. The budget is not a serialized value — it only decides when the collector stops — so this is not gated behind the v9 work.

Note the sample timestamps themselves (new PerformanceCollectionData(options.getDateProvider().now().nanoTimestamp())) are deliberately untouched: those are serialized into profile measurements, and re-anchoring them is §C1 / JAVA-578.

💡 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 performance-collection budget only)
• part of: Remaining low-priority clock issues and clock-step regression coverage #5582

💚 How did you test it?

The two existing 30 second tests in DefaultCompositePerformanceCollectorTest now advance a ticker instead of stubbing dateProvider.now() with a positional sequence of four return values:

whenever(mockDateProvider.now()).thenReturn(dates[0], dates[0], dates[0], dates[1])

That was brittle against any change in how often the date provider gets called, and it is what let the wall-clock dependency sit here unnoticed. All 20 tests in the class pass.

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

Three details worth a reviewer's eye:

1. The 30 second boundary is now inclusive — Deadline.hasPassed() is >=, where the old comparison was a strict >. A sample landing exactly on 30.000s now ends collection instead of being kept.
2. addDataAndCheckTimeout no longer takes a shared nowNanos. That parameter existed so one clock reading was shared across every transaction in a collection round; with a per-transaction Deadline there is nothing to share, and the nanosecond spread across one loop cannot matter to a 30 second budget. Say the word if you would rather keep the shared reading.
3. TestMonotonicTicker's backing field is now @Volatile, because the collector's timer thread reads a ticker that the test thread advances. (The companion HostnameCache PR does not need this — executorService.submit gives that path a happens-before edge.)

🔮 Next steps

§C6 also mentions the 100ms sampling loop in this same class running on java.util.Timer, whose deadlines are wall-clock and whose Object.wait() does not progress in Android deep sleep. Deliberately not in this PR: it is a scheduling change rather than a TTL one, it needs either a periodic API on ISentryExecutorService or a self-rescheduling task, and six tests in this class assert directly against an injected mock Timer. It deserves its own review.

The other two §C6 sites — profiling-trace cleanup in Sentry.java and envelope rotation in CacheStrategy — both compare against File.lastModified(), which is inherently a wall-clock value written by another process; there is no monotonic quantity to compare it against, so they are not fixable as stated.

🤖 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