feat: Add filter for root spans

[pulpdrew]

Closes HDX-2772

This PR adds a filter that allows for quickly viewing just root spans from a Trace source.

Notes:

• The state of this filter is persisted in the URL Query Params
• This filter is not persisted in a saved search to match the behavior of other filters, which are not persisted in saved searches.

[changeset-bot]

🦋 Changeset detected

Latest commit: e8dd6dd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@hyperdx/app	Patch
@hyperdx/api	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
hyperdx-v2-oss-app	Ready	Preview	Comment	Nov 12, 2025 9:00pm

[claude]

PR Review - Root Spans Filter

✅ No critical issues found.

The implementation is clean and follows project patterns well:

• ✅ Properly checks for source kind and parent span ID expression before rendering
• ✅ Uses consistent Mantine UI components and follows existing checkbox pattern
• ✅ State is correctly persisted in URL via filter mechanism
• ✅ Logic is well-encapsulated in setRootSpansOnly and isRootSpansOnly functions
• ✅ Handles empty string as the filter value for root spans (spans with no parent)

Minor enhancement opportunity (optional):
Consider adding test coverage for the new root spans filter in DBSearchPageFilters.test.tsx to match the existing test patterns for other filter functionality. The current tests cover the FilterGroup component but not the full DBSearchPageFilters component with the new checkbox.

[github-actions]

E2E Test Results

✅ All tests passed • 40 passed • 3 skipped • 303s

Status	Count
✅ Passed	40
❌ Failed	0
⚠️ Flaky	0
⏭️ Skipped	3

View full report →

[MikeShi42]

Thoughts on directly setting the filters object as opposed to a specific property? Or does it not work there?

[pulpdrew]

I did think about doing it that way, but decided against it because

1. Our filter states are based on parsing SQL, so we'd need to ensure our filter is of the form parentSpanId IN (''). This is probably fine, though less straightforward to me than empty(parentSpanId)
2. Our UI filter states are based on the values parsed from the filters parameter, so without specifically handling the parentSpanId filter when parsing, we'd end up with parentSpanId in the filter sidebar. We could specifically handle that, but that didn't seem any better to me than using a separate param.

Curious if you see a major benefit to having this in the filters object instead though - we could do it if there is one!

[MikeShi42]

Yeah I'm a bit split on this, that makes a lot of sense why it doesn't work well today. I can imagine in the future we have other filter settings that are just "preset filter combos" kind of thing (though no concrete use case yet). Might just be a more scalable solution long term.

[pulpdrew]

The idea of preset filter combos makes sense. For a preset filter combo, do you think we'd want to continue showing all the filters that have been applied by the preset, or hide the related filter sections?

For example, in this case, show or hide the ParentSpanId section here?

[pulpdrew]

We chatted offline and decided to go with using filters instead. We will show the related filter as applied in the sidebar (like the image above) but with an (empty) label.