Allow filtering/sorting profiles by their own captured duration, not just transaction span.duration
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 21h 10m
- Merged PRs (30d)
- 635
Description
### Problem Statement
Original conversation [here](https://app.intercom.com/a/inbox/onh0p2wm/inbox/team/9956409/conversation/215474985594077).
When I'm in Profiling (Transaction Summary → Profiles, or Explore), I want to find profiles whose own captured duration is long, for example "profiles over 10s", but there's no way to express that today.
Every profile-facing view runs on the spans dataset, where the only duration available is the transaction's wall-clock span.duration / `transaction.duration`. So filtering `span.duration:>10s` returns long transactions, which is a different thing: an 11.11s transaction can carry a profile that's only 4.13s (transaction duration includes idle/wait time like I/O, network, main-thread waits, app-start tails, while the profile only reflects the actively-sampled window). Users reasonably read the mismatch as the filter being broken, when in reality the metric they care about (the profile's duration) simply isn't filterable or sortable anywhere in the UI. There's also no duration shown per profile in the aggregate flamegraph's "Profiles" side panel, so the value can't even be eyeballed.
### Solution Brainstorm
- Expose a profile-duration dimension that can be filtered and sorted in profile-facing views (Transaction Summary → Profiles, Explore, Profiling landing). The field already exists on the legacy profiles dataset (`profile.duration` → `duration_ns` in [src/sentry/search/events/datasets/profiles.py](https://github.com/getsentry/sentry/blob/6752ad06b5a84c81ecea1c0a3852aaa9e311a6ec/src/sentry/search/events/datasets/profiles.py)) and there's an orphaned `profile.duration` column in [static/app/components/profiling/profileEventsTable.tsx](https://github.com/getsentry/sentry/blob/6752ad06b5a84c81ecea1c0a3852aaa9e311a6ec/static/app/components/profiling/profileEventsTable.tsx), but nothing feeds it now that these flows query the spans dataset.
- Show a duration column per profile in the aggregate flamegraph "Profiles" side panel ([aggregateFlamegraphSidePanel.tsx](https://github.com/getsentry/sentry/blob/6752ad06b5a84c81ecea1c0a3852aaa9e311a6ec/static/app/components/profiling/flamegraph/aggregateFlamegraphSidePanel.tsx)) so it's visible and verifiable.
- As a cheap near-term step, label/tooltip the span.duration filter on the Profiles tab to make clear it targets the transaction's duration, reducing the transaction-vs-profile confusion.
### Product Area
Profiling
Contributor guide
Research direction
Start by comparing the legacy profile.duration mapping in src/sentry/search/events/datasets/profiles.py with the orphaned column in static/app/components/profiling/profileEventsTable.tsx. Then inspect static/app/components/profiling/flamegraph/aggregateFlamegraphSidePanel.tsx and the profile-facing views to determine which duration filtering, sorting, and display scope is feasible. Done should make profile duration filterable or sortable and/or visibly distinguish it from transaction span.duration, according to the selected scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, typescript
- Domain
- frontend, observability-sre, performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100