fix: Group alert histories by evaluation time

[pulpdrew]

Closes HDX-2728

Summary

This PR groups AlertHistory records by createdAt time to avoid showing multiple alert histories for the same time on the alerts page. There can be multiple AlertHistory records for the same createdAt time for grouped alerts

Testing

To test this, setup a Saved Search alert with a group by configured, then navigate to the alerts page to see one history per time:

[changeset-bot]

🦋 Changeset detected

Latest commit: df32655

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

This PR includes changesets to release 2 packages

Name	Type
@hyperdx/api	Patch
@hyperdx/app	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 10, 2025 7:20pm

[claude]

PR Review

✅ Overall assessment: Well-implemented feature with excellent test coverage. One minor issue to address.

Issues

• ⚠️ Type mismatch in controller return type (packages/api/src/controllers/alertHistory.ts:23) → The function returns Omit<IAlertHistory, "alert">[] but the actual returned objects have createdAt as Date while the API response needs string. The frontend expects AlertHistory type from common-utils which has createdAt: string. Either update the return type to match the actual shape or ensure date serialization is handled correctly.

Strengths

• Comprehensive test coverage with 12 test cases covering edge cases
• Clean aggregation pipeline implementation
• Proper state logic (ALERT takes precedence over OK)
• Follows MongoDB aggregation patterns correctly

Minor observations (non-blocking)

• Consider adding an index comment for the { alert: 1, createdAt: -1 } index in alertHistory.ts since this query pattern is now critical
• The aggregation could potentially be optimized with $first for lastValues sorting, but current approach is clear and maintainable

[github-actions]

E2E Test Results

✅ All tests passed • 39 passed • 3 skipped • 312s

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

View full report →

[wrn14897]

any reason we don't want to do the aggregation on the db level? like computing isOk and all that

[pulpdrew]

My only concern with that was potentially breaking the API by changing the response format, requiring us to coordinate fronted and backend deployment. I can probably keep the format similar enough to avoid issues though, so I will give that a try.

[pulpdrew]

Updated 👍

[wrn14897]

Great fix!