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.

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, or no chunk covers the window	NOT_RECORDED

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 returns 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 is judged by the chunks that are left.
• A profiler id from a profiler instance that a second Sentry.init replaced reads as NOT_RECORDED. Keeping such ids alive belongs to whatever owns the profiler lifecycle across inits, not to the chunk history.

[github-actions]

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

Generated by 🚫 dangerJS against 31b6ce5

[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 💯

[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 07e9b69. Configure here.}

[cursor]

Close marks recorded chunks that never send

Medium Severity

close(true) calls stopInternal before isClosed is set. When the OS result is already available, endAndCollect runs onChunkCollected inline, sees isClosed as false, and marks a valid trace as RECORDED. sendChunk is then submitted off-thread; after isClosed flips, that task drops the chunk. markLastChunkNotRecordedIfUnknown does not touch a RECORDED record, so finishing transactions keep a profiler_id for a profile that is never sent.

Additional Locations (2)

• sentry-android-core/src/main/java/io/sentry/android/core/PerfettoContinuousProfiler.java#L467-L472
• sentry-android-core/src/main/java/io/sentry/android/core/PerfettoContinuousProfiler.java#L273-L279

 

^{Reviewed by Cursor Bugbot for commit 07e9b69. Configure here.}

[0xadam-brown]

Looks like this one's worth fixing.

PerfettoContinuousProfiler.close(true) has two jobs: stop the current profiling chunk and mark the profiler as closed so no more chunks are sent. But those two decisions are ordered in a way that lets one callback observe the old state and another step observe the new state, meaning a chunk can be marked as recorded in history even though shutdown guarantees it will never be sent.

[0xadam-brown]

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

[0xadam-brown]

Worth a quick Javadoc reminding folks that this logic should be kept in sync with the rules we use on the backend to decide which chunks to display for a given transaction – at least until our hoped-for tombstone protocol shows up 😄.

[0xadam-brown]

Suggested change

	// A chunk that is still running has no end yet, and covers everything from its start on
	// A chunk that is still running has no end yet, and covers everything from its start onward

[0xadam-brown]

(Fwiw, at first I thought the sentence had been truncated.)

[0xadam-brown]

Looks like this one's worth fixing.

PerfettoContinuousProfiler.close(true) has two jobs: stop the current profiling chunk and mark the profiler as closed so no more chunks are sent. But those two decisions are ordered in a way that lets one callback observe the old state and another step observe the new state, meaning a chunk can be marked as recorded in history even though shutdown guarantees it will never be sent.

[0xadam-brown]

Thoughts about replacing with a default method on IConinuousProfiler that returns UNKNOWN (same throughout)?