-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Security Solution][Detection Alerts] Fixes follow-up alert refresh bugs #112169
Conversation
9ce2833
to
e844acc
Compare
@elasticmachine merge upstream |
a9e0ccc
to
b92715f
Compare
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
b92715f
to
55010df
Compare
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.
Checked out, desk tested locally and code-reviewed -- Loooks GREEEEAT To Me! 👍 Thanks for following through with the thoroughness in fixes here @dplumlee! Everything I tested refreshed as expected and I identified no stale data when performing actions 🙂
Testing notes:
- Updating alert status from
Alert Details
closes flyout? I think this is desired UX, but was unexpected to me (I think this I mentioned this in the last PR 😅) . - Closing alert from
Alert Details
Add Exception UI
keeps flyout open, so slightly different UX from above with same action outcome. - Updating alert status from
Alert Details
->Investigate in Timeline
->Close Alert
->Close Timeline
, still showsclose action
in Alert Details flyout actions (Quite the corner case 😅 -- no resolution expected here).
cy.get(ALERT_COUNT_TABLE_FIRST_ROW_COUNT).should('have.text', `${expectedNumberOfAlerts}`); | ||
|
||
goToAcknowledgedAlerts(); | ||
waitForAlerts(); | ||
|
||
cy.get(ALERTS_COUNT).should('have.text', `${numberOfAlertsToBeMarkedAcknowledged} alert`); | ||
cy.get(ALERT_COUNT_TABLE_FIRST_ROW_COUNT).should( | ||
'have.text', | ||
`${numberOfAlertsToBeMarkedAcknowledged}` | ||
); |
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.
Is there a case for verifying the Trend
histogram has refreshed as well? No explicit counts visible in that component, so we'd need a separate method for verification here -- perhaps setup test to only have one alert and then verify Rule Name
is no longer in legend? Or could hover on a bar and verify counts in tooltip (though may be tough to sort out the flake)?
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.
Same comment goes for opening
/closing
specs below.
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 doesn't verify the trend histogram yet, I was looking at some possible ways to do that since the data isn't as neat from a css selector standpoint for cypress. I think having the one alert would be a good way to do that, though, I'll add it to the test case here and in the other relevant files 👍
if (routeProps.pageName === 'alerts') { | ||
refetchQuery(globalQuery); | ||
} |
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.
Nice! I had explicitly tried closing an alert from within timeline elsewhere in the app to see if we'd still refetch, haha! 😅
🚀 🥮
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: you could use https://github.com/elastic/kibana/blob/master/x-pack/plugins/security_solution/common/constants.ts#L72 instead of this string JUST IN CASE it ever changes
@@ -37,7 +37,7 @@ export const useUpdateAlertsStatus = ( | |||
const { http } = useKibana<CoreStart>().services; | |||
return { | |||
updateAlertStatus: async ({ status, index, query }) => { | |||
if (['detections-page', 'detections-rules-details-page'].includes(timelineId)) { | |||
if (useDetectionEngine) { |
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.
May want to rename -- wasn't immediately clear how the detection engine wasn't involved with updating alert status, but clicking through to see the conditional showed this is just a feature flag check between legacy impl and RAC RBAC routes. I guess this makes sense since the route ends up not being a DE route, but RAC, so don't mind me....
Do need some JSDocs though, haha 😉
@@ -1054,7 +1054,7 @@ Array [ | |||
</div> | |||
</EuiFlyoutBody> | |||
</Styled(EuiFlyoutBody)> | |||
<Memo() | |||
<Connect(Component) |
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.
Not for you to resolve, so commenting for posterity, but it's probably time we revisit some of these larger snapshot tests and determine if they can be broken up into smaller more understandable/maintainable chunks. We've discussed before how they lose their utility when reaching thousands of lines, and I think this is a reasonable example of this. (I identified the structural changes that resulted from this PR, but tough to make sense if that's all that changed that should have.)
55010df
to
acbe509
Compare
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.
code lgtm 👍 , but might be a good idea to get @angorayc to sign off on this before merging, i know there were some strange bugs with refetch in very specific circumstances that were recently fixed
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @dplumlee |
…ugs (#112169) (#114650) Co-authored-by: Davis Plumlee <[email protected]>
…ugs (#112169) (#114649) Co-authored-by: Davis Plumlee <[email protected]>
Summary
Follow-up to #111042
Addresses #112011
Checklist
Delete any items that are not applicable to this PR.
For maintainers