feat(profiling): Drop profiler ids from spans no profile covers

[markushi]

📜 Description

Transactions and spans are tagged with the continuous profiler's profiler_id as soon as they start, but the OS only tells us later whether a Perfetto profile really exists. This PR lets anything tagged with an id that leads nowhere drop the reference before it is sent.

IContinuousProfiler gets one new method:

@NotNull ProfileRecordingState getProfileRecordingState(
    SentryId profilerId, SentryDate startTime, SentryDate endTime);

SentryTracer.finish() asks it once for the root span window and once per child span window, and removes the ProfileContext plus the profiler_id span data only on NOT_RECORDED. RECORDED and UNKNOWN change nothing, so an outcome we do not know never costs a valid link. Only a window whose chunks all failed loses the id: a window no chunk covers stays UNKNOWN, as it may reach further back than the history, or a back-dated span may read as outside the chunk it ran in.

PerfettoContinuousProfiler answers from a bounded history of chunk records, guarded by a lock of its own so that a finishing transaction never waits for a chunk start, a chunk stop or an OS callback. The answer for a window follows one policy:

Scenario	Answer
No chunk ever ran	UNKNOWN
A chunk covering part of the window was recorded	RECORDED
No covering chunk was recorded, but one has no outcome yet	UNKNOWN
Every covering chunk failed	NOT_RECORDED
No chunk covers the window	UNKNOWN

The outcome of a chunk has a single owner on each side. PerfettoProfiler only ever reports a failure — an OS error code, a missing or empty trace file, or the result timeout — as soon as it knows, which is what makes the common rate-limit case cheap. PerfettoContinuousProfiler alone declares a chunk recorded, from the trace file it actually received, since the OS can report success and still leave nothing usable behind. NOT_RECORDED is final, so a result the OS delivers late cannot revive a chunk that was already given up on.

NoOpContinuousProfiler, AndroidContinuousProfiler and JavaContinuousProfiler answer UNKNOWN, which leaves every non-Perfetto path exactly as it was.

This is an alternative to #5993, which solved the same problem with callbacks from the profiler into the tracer. Pulling the state at send time removes the listener registration, the unregistration on finish, and the tracers that stay registered because they never finish.

💡 Motivation and Context

Rate limiting is the common case on API 35+, and the OS reports it roughly 1 ms after the request. Without this, a rate-limited session produces transactions that link to profiles the backend never receives, which shows up in the UI as dangling profile references. There is no backend logic that removes such references.

💚 How did you test it?

Unit tests, on three levels:

• ChunkRecordTest — the state machine (NOT_RECORDED is final), whether a chunk has ended, and the window arithmetic, including the exact boundaries and a chunk that is still running.
• PerfettoProfilerTest — the record outcome for an OS error, a null result path, a missing trace file, the result timeout, and a result that arrives after the timeout, plus the two cases where a successful result leaves the record untouched.
• PerfettoContinuousProfilerTest — the answer for a running chunk, a chunk that is still being collected, a collected chunk, a failed chunk, a failed and an unknown chunk under one window, a window after the last chunk, a window that starts before the profiler did, per-chunk judgement across a failed and a recorded chunk, eviction, and close.
• SentryTracerTest — dropped, kept and unknown outcomes, per-span judgement, a span that never finished, and a profiler_id the SDK did not write.

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

🔮 Next steps

Known limits, left out deliberately:

• PerfettoProfiler.start(long) was public and is now package-private, since it takes the internal chunk record. The class is @ApiStatus.Internal and @RequiresApi(35), but the method was on the published surface in 8.51.0–8.53.0.
• Only SentryTracer drops the id. OpenTelemetry spans take another path and are not covered. This has no effect today, as only the Android Perfetto profiler ever answers anything but UNKNOWN.
• Chunks that Sentry itself drops after a valid trace file was produced — a client-side rate limit, or cache eviction while offline — still read as recorded. The scope here is the OS reporting that no profile exists.
• The chunk history holds 10 chunks, so about 10 minutes. A transaction older than that reads as a transaction no chunk covers, and keeps its id.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 24de24c

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

[markushi]

@sentry review

[0xadam-brown]

Nice! Much easier to follow, IMO. A few initial comments. Haven't checked for any threading issues. But the APIs are looking clean 💯

[0xadam-brown]

A few minor comments + worth addressing the SentryBot issue; otherwise lgtm

[runningcode]

Thanks for taking on this complicated fix! Looks good! I left a two comments, one with a locking issue and the other with a clock issue. Let me know if you'd like to discuss either.

It's also valid to say they aren't blockers or to do them in a follow up so I'll approve this for now.

[cursor]

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

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1253a86. Configure here.}