[Security Solution] Rule information is not displayed under rule details page after deleted the rule

[ghost]

Describe the bug
Rule information is not displayed under rule details page after deleted the rule

Build Details:

Version: 8.0.0-SNAPSHOT
Commit: a29e0164a4af4d3135910cac9e6caa4478af5f3b
Build:48868

Browser Details:
N/A

Preconditions

1. Kibana should be running on 8.0.0 snapshot
2. Rule should be created and alerts should be generated

Steps to Reproduce

1. Navigate to rules tab under security
2. Delete the created rule
3. Navigate to Alerts tab
4. Click on view details icon of alerts of deleted rule
5. Click on rule name in alerts detail flyout
6. Observe that rule information is not displayed under rule details page

Actual Result
Rule information is not displayed under rule details page after deleted the rule

Expected Result
Rule information should be displayed under rule details page after deleted the rule

What's Working

• This issue is not occurring on 7.16.0
  

What's Not Working

• N/A

Screen-Shot

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[rylnd]

Related issue: #120562

[MadameSheema]

@deepikakeshav-qasource can you please validate the fix of this issue on 8.0.0 branch? Thanks! :)

[ghost]

Hi @MadameSheema ,

We have validated this issue on 8.0.0 branch and observed that issue is Partially Fixed. Rule information is displayed. however, error message is displayed under rule details of deleted rule

Please find the below testing details:

Build Details:

Version: 8.0.0 master branch
Build:9007199254740991

Screencast:

rule_delete.mp4

Observation on 7.16.0
No error is displayed under rule details page of deleted rule

Screencast:

Alerts.-.Delete_7.16.0.mp4

Thanks!!

[MadameSheema]

@spong can you please take a look at the above observation? Thanks :)

[spong]

Checked out latest 8.0 and tried to reproduce locally and was unable to repro 500 error. Instead I was seeing a 404 (as expected) for /kbn/internal/detection_engine/rules/_find_status which is suppressed from being displayed as an error toast in the UI:

kibana/x-pack/plugins/security_solution/public/detections/containers/detection_engine/rules/use_rule_status.tsx

Lines 47 to 51 in 6c3dcb6

	if (isSubscribed && !isNotFoundError(error)) {
	setRuleStatus(null);
	addError(error, { title: i18n.RULE_AND_TIMELINE_FETCH_FAILURE });
	}
	}

kibana/packages/kbn-securitysolution-t-grid/src/utils/api/index.ts

Lines 40 to 42 in 4fa3dc4

	export const isNotFoundError = (error: unknown) =>
	(isKibanaError(error) && error.body.statusCode === 404) ||
	(isSecurityAppError(error) && error.body.status_code === 404);

---

So the question here is why are you seeing a 500 error when attempting to fetch the rule status. The error toast being displayed here is technically as-designed since we intend to only hide 404 errors.

Are there any additional steps you may be taking in recreation here that could be resulting in this behavior @deepikakeshav-qasource? Did the rule have any historical failures (shown in the Failure History tab) before it was deleted? I tried reproducing by deleting a rule with active warnings and wasn't able to get a 500 there either. Was this part of an upgrade test by chance, or entirely on a fresh 8.0 install? Were you seeing this error on other rules that hadn't been deleted?

[ghost]

Hi @spong ,

Are there any additional steps you may be taking in recreation here that could be resulting in this behavior

No, We did not performed any additional steps. We created the custom query rule then generate the alerts and delete the rule.

Did the rule have any historical failures (shown in the Failure History tab) before it was deleted?

No, Not any historical failures is displayed in Failure history tab before deleted. Please find below screencast for same.

Was this part of an upgrade test by chance, or entirely on a fresh 8.0 install?

This is not upgrade path, we have tested on 8.0.0 branch

Were you seeing this error on other rules that hadn't been deleted?

No, We only able to see this error on deleted rule. please find the below screencast.

Screencast:

Rules_delete1.mp4

Please let us know if any other information is required from our end. :)

Thanks!!

[spong]

Hrmm, still no luck reproducing against latest (commit 29165d5). Still getting 404's, which are suppressed in the UI.

When you say Build:9007199254740991 -- where is this build number coming from? I'm not seeing it over on https://buildkite.com/elastic. Do you have a corresponding commit hash from this build so I can verify I'm testing against the same? Thanks!

[ghost]

Hi @spong ,

Earlier latest changes were not merged to the cloud build. So we tested this ticket on 8.0.0 branch.

We use the localhost:5601/status URL to check the build details.

Today, the latest changes are merged on cloud and we also tested the same on cloud build and facing the same issue.

Please find the below details:

Build Details:

Version: 8.0.0 Snapshot
Build:49040
Commit: 155e06787e48de9a8de4345d86a826e95edf32ec

Screencast:

Rules.mp4

Please let us know if we can share the build details through email.

Thanks!!

[MadameSheema]

@spong @banderror any update on this issue? Thanks!

[spong]

@MadameSheema -- I've been unable to reproduce the reported 500 locally and haven't been able to debug this behavior further. That said, if they're getting a 500 on this page, seeing an error toast is expected (as above), and since the rule data is now showing we can probably mark this as impact:low until the 500 error is more reliably reproduced. I can spend some more time trying to reproduce come 8.1 FF and if there's still more that needs to be addressed here we can target 8.0.1/8.1 with a follow-up fix. Does that sounds good?

[MadameSheema]

Sounds good to me @spong, lots of thanks for the clarification :)

[pborgonovi]

Validated BC 8.15 and wasn't able to reproduce. Keeping this open due to @spong comment above.

[spong]

We can probably close this then. There's a bit of history here and if we can't reproduce now it might be best to just open a new issue if/when it surfaces again. Going to swap assignments to @banderror since I'm on a different team now.

[banderror]

Unable to repro, closing.