elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.73k stars 8.14k forks source link

Custom filter warnings incorrectly shown on the rule editing page #181643

Open nikitaindik opened 5 months ago

nikitaindik commented 5 months ago

We've recently received SDH #945 (internal). The issue there seems to be caused by a bug on the rule editing page. When editing a rule with custom filters, QueryBar displays warnings for filters, even though there's nothing wrong with filters' configuration.

It's a UI-only issue. It doesn't affect submitted data or rule execution.

The issue reproduces only if you go into edit mode by clicking the "Edit rule settings" button. It works as expected if you navigate to the edit page directly or if you reload the edit page.

filter_warning

Kibana version: 8.11.x

Steps to reproduce: (also see video below)

  1. Start creating a new custom query rule
  2. Choose "Data view" as source and select a data view (for example: logs-*)
  3. Fill in anything as a Custom query (for example: *)
  4. Add a new custom filter (for example: {"regexp":{"file.path":{"value":".*abc"}}})
  5. Notice that the newly added filter is shown as green
  6. Fill in other required fields and save the rule
  7. Click "Edit rule settings" to go into edit screen for this rule
  8. Notice that the filter is now yellow (has a warning) and if you hover over it you see a tooltip: "Field query does not exist in current view"
  9. Reload the edit page
  10. Notice that the filter is green again

https://github.com/elastic/kibana/assets/15949146/4d841d6f-b46f-44e9-bf3a-403264d0b872

Expected behavior:

Any additional context: There seems to be a race condition.

  1. EditRulePageComponent: We fetch indexPattern using the useRuleIndexPattern hook. Initially, while the hook is still fetching, it returns an "empty" object { fields: [], title: "" } This "empty" object is passed down the components tree as indexPattern prop until it reaches the QueryBar component.
  2. QueryBar has a useEffect that listens for indexPattern changes. QueryBar's useEffect checks whether the indexPattern prop value is a data view.

If it's a data view: it sets it into state (and uses it later to render filters). If it's not a data view: the code inside useEffect creates a data view from it using an async call like this: dv = await data.dataViews.create({ id: indexPattern.title, title: indexPattern.title });

  1. In our case this "empty" object is not a data view, so useEffect tries to create a data view from it. The "await" begins. ...
  2. EditRulePageComponent: A moment later useRuleIndexPattern finishes fetching the index pattern and returns it instead of an "empty" index pattern. This proper object is passed down the components tree as indexPattern prop until it reaches the QueryBar component.
  3. QueryBar's useEffect checks whether "indexPattern" prop is a data view. It is, so it sets it into state directly, without doing any async calls.
  4. A moment later the await from step 3 resolves and returns an empty data view created from an "empty" indexPattern prop. This data view object is then set into state, replacing the good data view that was set in step 5.
  5. QueryBar now has an empty data view in its state. It then passes it to the FilterItem component as a prop. FilterItem shows a warning.

To fix this we might consider:

Similar SDH issue with some background info: https://github.com/elastic/sdh-kibana/issues/3254

elasticmachine commented 5 months ago

Pinging @elastic/security-detection-engine (Team:Detection Engine)