Description
ANR profile chunks are currently counted against customers' Continuous Profile Hours quota rather than UI Profile Hours. Continuous Profile Hours are on a different price curve and are not the intended billing bucket for this feature.
Root cause
ApplicationExitInfoEventProcessor builds ANR ProfileChunks using ProfileChunk.PLATFORM_JAVA. Relay's ProfileType::from_platform matcher maps "java" → ProfileType::Backend → profile_chunk data category (Continuous Profile Hours). The Android SDK's regular continuous profiles correctly use platform = "android" → ProfileType::Ui → profile_chunk_ui data category (UI Profile Hours).
The mismatch arose because ANR profiles were built to reuse the existing ProfileChunk carrier rather than introduce a new envelope item, and the convenience came at the cost of billing ambiguity at the ingest boundary.
Coupling note
Issues 1 and 2 both root in this same platform string. The platform flip that fixes billing ("java" → "android") is the same change that routes the chunk to the correct symbolication pipeline. The two fixes should ship together.
Proposed fix
- SDK (
sentry-java): Change ApplicationExitInfoEventProcessor.captureAnrProfile to emit platform = "android" (or a new PLATFORM_ANDROID_ANR constant) on ANR ProfileChunks. Verify that the ANR chunk's JVM frames (module, function, filename, lineno, no instruction_addr) flow cleanly through vroom's Android call-tree derivation path — the Android continuous-profile path already handles this shape, so the precedent is established.
- Relay (
getsentry/relay): Confirm the existing "android" match arm in ProfileType::from_platform is sufficient, or add an explicit arm if a distinct constant is introduced.
Going forward
- Possible longer term approach: Add a
profile_kind: "anr" field to the chunk schema to decouple billing from platform entirely, and add a new envelope item type profile_chunk_anr so the ingest router can dispatch on it directly without overloading the platform string. (Out of scope.)
Difficulty
Low
Repos affected
sentry-java (primary), getsentry/relay (coordination required)
Description
ANR profile chunks are currently counted against customers' Continuous Profile Hours quota rather than UI Profile Hours. Continuous Profile Hours are on a different price curve and are not the intended billing bucket for this feature.
Root cause
ApplicationExitInfoEventProcessorbuilds ANRProfileChunks usingProfileChunk.PLATFORM_JAVA. Relay'sProfileType::from_platformmatcher maps"java"→ProfileType::Backend→profile_chunkdata category (Continuous Profile Hours). The Android SDK's regular continuous profiles correctly useplatform = "android"→ProfileType::Ui→profile_chunk_uidata category (UI Profile Hours).The mismatch arose because ANR profiles were built to reuse the existing
ProfileChunkcarrier rather than introduce a new envelope item, and the convenience came at the cost of billing ambiguity at the ingest boundary.Coupling note
Issues 1 and 2 both root in this same platform string. The platform flip that fixes billing (
"java"→"android") is the same change that routes the chunk to the correct symbolication pipeline. The two fixes should ship together.Proposed fix
sentry-java): ChangeApplicationExitInfoEventProcessor.captureAnrProfileto emitplatform = "android"(or a newPLATFORM_ANDROID_ANRconstant) on ANRProfileChunks. Verify that the ANR chunk's JVM frames (module,function,filename,lineno, noinstruction_addr) flow cleanly through vroom's Android call-tree derivation path — the Android continuous-profile path already handles this shape, so the precedent is established.getsentry/relay): Confirm the existing"android"match arm inProfileType::from_platformis sufficient, or add an explicit arm if a distinct constant is introduced.Going forward
profile_kind: "anr"field to the chunk schema to decouple billing from platform entirely, and add a new envelope item typeprofile_chunk_anrso the ingest router can dispatch on it directly without overloading the platform string. (Out of scope.)Difficulty
Low
Repos affected
sentry-java(primary),getsentry/relay(coordination required)