Repository navigation
fix(api): read previous alert history with one index seek per group #3509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
345fec9
1abe091
bf3daf2
6ccc760
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| --- | ||
| '@hyperdx/api': patch | ||
| --- | ||
|
|
||
| fix: Grouped alerts with many groups no longer slow down every alert check: the previous state of each group is read in one query with one index seek per group, instead of every history row of the last 7 days. The API builds a new AlertHistory index `{alert, group, createdAt, state}` at startup and then drops the `{alert, group, createdAt}` index it replaces. On a large AlertHistory collection the index build takes a while; checks keep using the old index until it is done. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -135,8 +135,11 @@ AlertHistorySchema.index( | |
| // Used by getRecentAlertHistories (matches on alert, sorts by createdAt) | ||
| AlertHistorySchema.index({ alert: 1, createdAt: -1 }); | ||
|
|
||
| // Used by getPreviousAlertHistories (groups by {alert, group}, sorts by createdAt) | ||
| AlertHistorySchema.index({ alert: 1, group: 1, createdAt: -1 }); | ||
| // Used by getPreviousAlertHistories (newest non-ERROR row per {alert, group}). | ||
| // `state` comes last so the ERROR exclusion is an index bound and the query | ||
| // keeps a DISTINCT_SCAN. Replaces {alert: 1, group: 1, createdAt: -1}, which | ||
| // dropReplacedAlertHistoryIndex (src/migrations.ts) drops at API startup. | ||
| AlertHistorySchema.index({ alert: 1, group: 1, createdAt: -1, state: 1 }); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🟠 major — Old {alert, group, createdAt} index is never dropped, so the busiest collection keeps both indexes on every deployment Mongoose Nothing blocks merge automatically, but a maintainer will expect this fixed if it is a real defect in code this PR changes. If it is about surrounding code, reply and say so instead of patching. Do not widen the PR. How to respond
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed in 6ccc760: the API now drops |
||
|
|
||
| export default mongoose.model<IAlertHistory>( | ||
| 'AlertHistory', | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔵 minor —
AlertHistory.init()makes API startup wait for the whole new index buildServer.start()awaitsrunStartupMigrations()atpackages/api/src/server.ts:103, andawait AlertHistory.init()doesn't resolve until Mongoose finishes building{alert, group, createdAt, state}. The changeset says that build "takes a while" on a large collection. Until it finishes, everything after line 103 waits:setupTeamDefaultsin local app mode, plus any startup migration added later. If the build fails,init()rejects and only an error is logged. Fix: don't await this step in the startup path (void dropReplacedAlertHistoryIndex().catch(log)), or run it after the other startup work.Advisory. Fix if it is a small defect in code this PR changes; otherwise reply in the thread. Do not widen the PR or touch files it did not already change. How to respond