-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Rename alert status OK to Recovered and fix some UX issues around disabling a rule while being in an error state #98135
Conversation
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
I can't find an issue for this, but I've been thinking it would be more useful for us to show instances that have recovered with a visual status of "recovered", instead of "ok" as it does today. Makes it more clear that it WAS active, previously. And set expectations that you aren't seeing all the potential range of alert instances, only those that have "alerted". Haven't looked at the size of this issue yet, but if we're doing a couple clean ups of this kind of stuff, this PR could be a place to put this. I think it involves just a change in the text we display in the instance table. |
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.
LGTM
re: ok -> recovered. I happened to think - "do we have doc to fix? maybe a screen shot?". Took a brief look - nope! Did I miss it? It ain't right that we don't have doc on the alert details UI! Let's open a new doc issue if we don't. I think this is probably release-note worthy though. It's possible some customers may be confused by the change of "OK" to "Recovered". We should note that the semantics have not changed; these have always been alert instances which were previously active but are no longer active, we just changed the label to better reflect that state. |
@@ -953,6 +953,11 @@ export class AlertsClient { | |||
), | |||
updatedBy: username, | |||
updatedAt: new Date().toISOString(), | |||
executionStatus: { | |||
status: 'pending', | |||
lastExecutionDate: new Date().toISOString(), |
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.
nit: Does it make sense to reset the lastExecutionDate
here? I guess it would quickly be overwritten the next time the rule runs, but technically, this date is not the last time the rule was executed.
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.
It looks like we do set that field to the same "current date" for other cases of status: 'pending'
. So, it's consistent. I think we picked the name lastExecutionDate
before starting to use pending
, and so ... the name kinda doesn't make sense any more. Would be better described (I think) as "lastStateUpdateDate" or something.
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.
Would be better described (I think) as "lastStateUpdateDate" or something.
I think that makes sense. Should I create an issue for 8.0 release? This way we can make it a breaking change.
I think copying how it's done on create is ok for now but definitely strange.
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.
DateDateDate
I'm not against changing the name to better reflect reality, especially as an 8.0 thing. Though I wonder if lastStateUpdate
makes sense - the date value is supposed to reflect the last execution, except we knew we didn't have that date in some previous 7.x release, and obviously don't have one for newly created rules. So it does kind of make sense to continue with the current name, with the caveat that you need to check to see if the status
is 'pending' which means "it hasn't run yet". Basically, if we call it lastStateUpdate
, would folks expect other changes might also change this date? What happens to these fields when disabling a rule?
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.
I read this as "the execution status is pending, and it's been pending since lastExecutionDate
". So any name that can reflect that and last time the rule executed I'm +1. Seems like a separate issue to be created?
@@ -463,6 +465,74 @@ describe('disable button', () => { | |||
handler!({} as React.FormEvent); | |||
expect(enableAlert).toHaveBeenCalledTimes(1); | |||
}); | |||
|
|||
it('should bring back error banner after re-enable if previously dismissed', async () => { |
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.
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.
After re-enabling the rule, it would have a pending
status which I believe explains why the banner doesn't re-appear until you refresh the page (or click the refresh button). Because by then, the rule had a chance to run once and update the execution status. Does this experience seem strange?
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.
Ah I see. I think that's fine. The test name made me think the error banner should reappear right away but I think it's ok if it doesn't.
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.
Ah, I see what you mean. I fixed the test name in this commit: 624ae75.
https://www.elastic.co/guide/en/kibana/master/rule-details.html We do have a screenshot for this |
I will update those for sure! |
I went ahead and updated the PR title and release note label for this 🙏 |
@@ -119,6 +119,7 @@ export default function createEnableAlertTests({ getService }: FtrProviderContex | |||
.auth(user.username, user.password) | |||
.expect(200); | |||
expect(typeof updatedAlert.scheduled_task_id).to.eql('string'); | |||
expect(updatedAlert.execution_status.status).to.eql('pending'); |
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.
Note to self: this is flaky in the scenario the rule finished running before the API call is made.
Error: expected 'ok' to sort of equal 'pending'
at Assertion.assert (/dev/shm/workspace/parallel/16/kibana/node_modules/@kbn/expect/expect.js:100:11)
at Assertion.eql (/dev/shm/workspace/parallel/16/kibana/node_modules/@kbn/expect/expect.js:244:8)
at Context.<anonymous> (test/alerting_api_integration/spaces_only/tests/alerting/enable.ts:52:55)
at Object.apply (/dev/shm/workspace/parallel/16/kibana/node_modules/@kbn/test/src/functional_test_runner/lib/mocha/wrap_function.js:73:16) {
actual: 'ok',
expected: 'pending',
showDiff: true
}
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.
Had to remove the integration test: cfb1c25. It will always be a race condition between enabling the rule and checking if the execution status is pending
. So we'll have to rely on unit tests.
@@ -49,6 +49,7 @@ export default function createEnableAlertTests({ getService }: FtrProviderContex | |||
.set('kbn-xsrf', 'foo') | |||
.expect(200); | |||
expect(typeof updatedAlert.scheduled_task_id).to.eql('string'); | |||
expect(updatedAlert.execution_status.status).to.eql('pending'); |
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.
Note to self: this is flaky in the scenario the rule finished running before the API call is made.
Error: expected 'ok' to sort of equal 'pending'
at Assertion.assert (/dev/shm/workspace/parallel/16/kibana/node_modules/@kbn/expect/expect.js:100:11)
at Assertion.eql (/dev/shm/workspace/parallel/16/kibana/node_modules/@kbn/expect/expect.js:244:8)
at Context.<anonymous> (test/alerting_api_integration/spaces_only/tests/alerting/enable.ts:52:55)
at Object.apply (/dev/shm/workspace/parallel/16/kibana/node_modules/@kbn/test/src/functional_test_runner/lib/mocha/wrap_function.js:73:16) {
actual: 'ok',
expected: 'pending',
showDiff: true
}
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.
Had to remove the integration test: cfb1c25. It will always be a race condition between enabling the rule and checking if the execution status is pending
. So we'll have to rely on unit tests.
This is updated in 8b41644. |
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.
LGTM!
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Async chunks
Unknown metric groupsReferences to deprecated APIs
History
To update your PR or re-run it, just comment with: cc @mikecote |
…abling a rule while being in an error state (elastic#98135) * Fix UX when alert is disabled and in an error state * Reset executionStatus to pending after enabling an alert * Renames alert instance status OK to Recovered * Fix end to end test * Update doc screenshot * Fix confusing test name * Remove flakiness in integration test Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…abling a rule while being in an error state (#98135) (#100063) * Fix UX when alert is disabled and in an error state * Reset executionStatus to pending after enabling an alert * Renames alert instance status OK to Recovered * Fix end to end test * Update doc screenshot * Fix confusing test name * Remove flakiness in integration test Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Mike Côté <mikecote@users.noreply.github.com>
* master: (27 commits) Disable contextMenu when event is not event.kind=event (elastic#100027) Updates the monorepo-packages list (elastic#100096) Removes circular deps for lists in tooling and bumps down byte limit for lists (elastic#100082) [Security Solutions] Breaks down the io-ts packages to decrease plugin size (elastic#100058) fix-typo: Use of `than` instead of `then` (elastic#100030) [Fleet] Fix error when searching for keys whose names have spaces (elastic#100056) [Workplace Search] Fix bug when transitioning to personal dashboard (elastic#100061) [index pattern field editor] Update runtime field painless docs url (elastic#100014) [QA] Switch tests to use importExport - visualize (elastic#98063) [Canvas] Remove unused legacy autocomplete component (elastic#99215) Re-enable formerly flaky shareable test (elastic#98826) [Uptime] [Synthetics Integration] ensure that proxy url is not overwritten (elastic#99944) [Security Solutions][Lists] Trims down list plugin size by breaking out the exception builder into chunks by using react lazy loading (elastic#99989) [Uptime] Increase debounce and add immediate submit to `useQueryBar` (elastic#99675) chore(NA): moving @kbn/docs-utils into bazel (elastic#100051) [Enterprise Search] Fix SchemaFieldTypeSelect axe issues (elastic#100035) Remove outdated comment about schema validation not working (it does work now). (elastic#100055) Rename alert status OK to Recovered and fix some UX issues around disabling a rule while being in an error state (elastic#98135) [Fleet] Do not use async method in plugin setup|start (elastic#100033) Skip flaky functional test suite ...
…abling a rule while being in an error state (elastic#98135) * Fix UX when alert is disabled and in an error state * Reset executionStatus to pending after enabling an alert * Renames alert instance status OK to Recovered * Fix end to end test * Update doc screenshot * Fix confusing test name * Remove flakiness in integration test Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Resolves #87055
Resolves #98073
In this fix-it PR, I'm fixing a couple of UX issues around the rule details page.
lastExecutionStatus
), the error banner will re-display after the user disables then enables the rule if the banner was previously dismissed. This way, if ever the rule does encounter a different error after being enabled, the error gets displayed regardless if they chose to dismiss the previous error or not.lastExecutionStatus
). A banner is already displayed to indicate the rule is disabled.pending
just like when a rule is created. This removes the confusion of seeing an error message in the rule details page when the rule didn't finish running yet (after being re-enabled).