[ResponseOps][Alerting] Unable to upgrade to 8.4.0 when I have snoozed rules #139427
Conversation
|
Pinging @elastic/response-ops (Team:ResponseOps) |
There was a problem hiding this comment.
LGTM! Left one comment about another unit test but otherwise looks great.
I verified this locally by:
- Running 8.2 and creating some rules:
8.2 rule never snoozed- didn't touch after creating8.2 rule snoozed indefinitely in 8.2- snoozed indefinitely after creating8.2 rule snoozed for 1 day in 8.2- snoozed for 1 day after creating8.2 rule snoozed then unsnoozed in 8.2- snoozed then unsnoozed after creating8.2 rule snoozed indefinitely in 8.3- didn't touch after creating8.2 rule snoozed for 1 day in 8.3- didn't touch after creating8.2 rule snoozed then unsnoozed in 8.3- didn't touch after creating
- Upgraded to 8.3, verified the rules ran successfully then:
- snoozed the
8.2 rule snoozed indefinitely in 8.3rule indefinitely - snoozed the
8.2 rule snoozed for 1 day in 8.3rule for 1 day - snoozed then unsnoozed the
8.2 rule snoozed then unsnoozed in 8.3rule - then created:
8.3 rule never snoozed- didn't touch after creating8.3 rule snoozed indefinitely in 8.3- snoozed indefinitely after creating8.3 rule snoozed for 1 day in 8.3- snoozed for 1 day after creating8.3 rule snoozed then unsnoozed in 8.3- snoozed then unsnoozed after creating
- snoozed the
- Upgraded to 8.4 and saw the migration fail due to these rules:
8.2 rule snoozed for 1 day in 8.38.2 rule snoozed for 1 day in 8.28.3 rule snoozed for 1 day in 8.3
- Ran this PR and saw the migration succeed. Snooze end date showed up correctly in the UI and saw the rules all run successfully.
x-pack/plugins/alerting/server/saved_objects/migrations.test.ts
Outdated
Show resolved
Hide resolved
| return { | ||
| ...doc, | ||
| attributes: { | ||
| ...(omit(doc.attributes, ['isSnoozedUntil']) as RawRule), |
There was a problem hiding this comment.
I believe the result of this fix is that a rule that was snoozed in 8.3 will no longer be snoozed in 8.4.1.
Given the urgency I'm 👍 on that, but we should probably make that clear in the 8.4.1 release notes.
|
@Zacqary as you know the snooze functionality better than anyone - can you help us verify this? I'm wondering what will happen to a rule that removed the |
@gmmorris When I tested this PR locally, I could still see the snooze in the UI after successful upgrade to 8.4. The PR that removed the mapping also calculates it on the fly, so I believe the snooze functionality should still work. Hopefully @Zacqary can confirm :) |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
|
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…d rules (elastic#139427) * Adding migration * Removing timer * Adding functional test * Adding another test (cherry picked from commit 8991e04) # Conflicts: # x-pack/plugins/alerting/server/saved_objects/migrations.ts # x-pack/test/alerting_api_integration/spaces_only/tests/alerting/migrations.ts # x-pack/test/functional/es_archives/alerts/data.json
…d rules (#139427) (#139486) * Adding migration * Removing timer * Adding functional test * Adding another test (cherry picked from commit 8991e04) # Conflicts: # x-pack/plugins/alerting/server/saved_objects/migrations.ts # x-pack/test/alerting_api_integration/spaces_only/tests/alerting/migrations.ts # x-pack/test/functional/es_archives/alerts/data.json
…d rules (elastic#139427) * Adding migration * Removing timer * Adding functional test * Adding another test
Resolves #139412
Summary
Added migration for
8.4.1to removeisSnoozedUntilChecklist