Skip to content
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

[RAM] Garbage collect expired snoozes #135271

Merged
merged 16 commits into from
Jul 11, 2022
Merged

Conversation

Zacqary
Copy link
Contributor

@Zacqary Zacqary commented Jun 27, 2022

Summary

Fixes #134726

Every time the task manager evaluates a rule, it will clear any expired snoozes from its snoozeSchedule. This solves the issue of expired snoozes being visible in the UI.

Checklist

@Zacqary Zacqary added release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Alerting/RulesManagement Issues related to the Rules Management UX v8.4.0 labels Jun 27, 2022
return {
id,
snoozeEndTime: new Date(MAX_TIMESTAMP),
};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole file is just a copy-paste of code removed from isRuleSnoozed, except for this check for duration === -1

I'm temporarily having an indefinite snooze return an end time of MAX_TIMESTAMP just to avoid type errors and allow snoozes to be sorted by duration effectively. This timestamp is never parsed in the code because the UI and task runner still rely on the muteAll property. When we take care of #132266 we can look into whether passing MAX_TIMESTAMP for indefinite snoozes is the right thing to do, or if we want to handle this case differently.

* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've only added tests for isSnoozeExpired because it's new code. isSnoozeActive is existing code moved to a new module, and all of its functionality is covered very robustly by the tests for isRuleSnoozed. IMO adding additional tests for isSnoozeActive would be redundant, unless we similarly pulled them out of the isRuleSnoozed tests.

@Zacqary Zacqary marked this pull request as ready for review June 28, 2022 17:55
@Zacqary Zacqary requested a review from a team as a code owner June 28, 2022 17:55
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@Zacqary Zacqary enabled auto-merge (squash) June 28, 2022 17:55
@Zacqary
Copy link
Contributor Author

Zacqary commented Jul 5, 2022

@elasticmachine merge upstream

@Zacqary
Copy link
Contributor Author

Zacqary commented Jul 7, 2022

@elasticmachine merge upstream

@Zacqary Zacqary requested a review from mikecote July 7, 2022 19:28
@Zacqary
Copy link
Contributor Author

Zacqary commented Jul 7, 2022

@elasticmachine merge upstream

@Zacqary
Copy link
Contributor Author

Zacqary commented Jul 8, 2022

@elasticmachine merge upstream

@Zacqary Zacqary requested a review from a team July 8, 2022 16:18
Copy link
Contributor

@JiaweiWu JiaweiWu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great! also love the tests, just had a question about a failure case potentially.

}
return null;
})
.map((snooze) => isSnoozeActive(snooze))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

);

const snoozeSchedule = attributes.snoozeSchedule
? attributes.snoozeSchedule.filter((s) => !isSnoozeExpired(s))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like isSnoozeExpired can throw, just curious to know what would happen if it does throw? I guess 1 invalid snooze could potentially prevent all other snoozes from being cleared. Maybe we should have some kind of recovery logic?

Copy link
Contributor

@JiaweiWu JiaweiWu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #43 / lens app - group 3 lens drag and drop tests basic drag and drop should combine field to existing horizontal dimension

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
triggersActionsUi 885.2KB 885.3KB +92.0B

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@Zacqary Zacqary merged commit c083997 into elastic:main Jul 11, 2022
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jul 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Alerting/RulesManagement Issues related to the Rules Management UX release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RAM] Snooze UX shows a rule as snoozed when it isn't
6 participants