[Security Solution] Filter editing causing Error: e.getName is not a function exception

[e40pud]

Describe the bug:

Filter editing on rule's editing page can cause an exception:

Error: e.getName is not a function
    at getLabel (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/plugin/unifiedSearch/1.0.0/unifiedSearch.chunk.1.js:1:32379)
    at Array.map (<anonymous>)
    at u (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/plugin/unifiedSearch/1.0.0/unifiedSearch.chunk.1.js:1:24215)
    at ua (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:59279)
    at ec (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:115190)
    at Ic (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:99978)
    at Nc (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:99800)
    at Dc (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:99633)
    at wc (https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:96466)
    at https://kibana-app.whitesector.inf.elasticnet.co/64715/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.dll.js:420:45201

After some investigation, we found that this happens here because indexPattern does not have a getName method.

The root cause is the incorrect type cast indexPatterns as DataView[] (from DataViewBase to DataView) that we do in several places around security solution code: 1, 2, 3, 4.

More details in slack https://elastic.slack.com/archives/CN7AD3605/p1692257845887359

Screenshots (if relevant):

20230817-0735-32.6812978.mp4

[elasticmachine]

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

[elasticmachine]

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

[e40pud]

@kqualters-elastic suggested to fix this with the next steps:

1. delete all the type casts
2. convert all DataViewBase types to DataView, at the last possible place in the code we own, like we do here: so we aren't possibly passing the non-serializable class instance around in redux by mistake or something + reduce the size of component state/props

[MadameSheema]

It would be great if we can fix this for 8.10 and 8.9.2 :)

[yctercero]

I think this is going to be a bigger fix than it may seem, as in, it will touch a lot of files, We may need to discuss any risk in backporting.

[dhurley14]

Have not been able to reproduce this so far. Neither on cloud nor locally. @aarju are you comfortable with providing an exported version of the rule? And a few more details that could be heplful.. Is that a data stream the rule is querying? Is this a rule that was created fresh in 8.9.0 or was the rule pre-existing prior to 8.9.0?

[dhurley14]

Just clarifying - I agree the code referenced is not safe, but I would feel more comfortable knowing it was fixed correctly if I was able to reproduce the bug.

[yctercero]

NOTE: #165262 went in as a fix but caused an infinite loop of calls to be made in rule creation and was reverted in #166176

[yctercero]

Hey @dhurley14 ! Was this addressed by #166318 ?

[dhurley14]

@yctercero I believe so! Been a while since I've seen this but I looked at the code and it seems the typeguard here should prevent the error from occurring: https://github.com/elastic/kibana/pull/166318/files#diff-e6442176bd5f8e996ee191a1b34c716e43c58ff4644adfcfca6dc98a386cb8caR41-R43