## Exceptions not created for mappings with conflicts

related: #177007


How to reproduce

- Execute request in order, and change timestamps to you actual dates
```
PUT test-1
{
  "mappings": {
    "properties": {
      "@timestamp": {"type": "date"},
      "host.name": { "type": "keyword" }
    }
  }
}

PUT auditbeat-1
{
  "mappings": {
    "properties": {
      "@timestamp": {"type": "date"},
      "host.name": { "type": "boolean" }
    }
  }
}

POST auditbeat-1/_doc
{
  "@timestamp": 1714121723789,
  "host.name":"host 11",
  "user.name": "123"
}

POST test-1/_doc
{
  "@timestamp": 1714121723789,
  "host.name":"host 11",
  "user.name": "123"
}

```

- Create a query rule, with index pattern `test-1` and the query: '*'.
Wait for the alert to be generated
- Go to the Alerts page (not from the Rule, but all alerts)
- Click add exception from the alert and observe that it says that
fields have conflict about auditbeat index. Which is incorrect as a rule
has only `test-1` index pattern.
- Check all checkboxes about closing alerts and creating exceptions. See
that there is no success toast, and the rule also has no exception.
- Open flyout exception again. Observe that there is no more message
about conflicts. If you create an exception it will be successful.




https://github.com/elastic/kibana/assets/7609147/d29981f7-5d6f-41b2-af46-2ade884e3563


### Reason

In the `AddExceptionFlyout` we do have this line

```
 const { isLoading, indexPatterns, getExtendedFields } = useFetchIndexPatterns(rules);
```

From `AlertContextMenuComponent` we are passing try to load the rule
info and first past `undefined` to rules and then some real info.

The problem is that in the `useFetchIndexPatterns` - if rules not
defined, we return `getExtendedFields` related to the default data view,
but no there rule index pattern.

And probably there some race conditions happen, and after we pass rules
props, exceptions don't rerender the info.

As a fix for this BC I just wait for rule info to be loaded, and then
render exception flyout, but it only masks the problem.

As we want to fix this bug faster, it's probably ok to merge it like
that. And there will be an issue to address this later.

---------

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

## Exceptions not created for mappings with conflicts

related: elastic#177007

How to reproduce

- Execute request in order, and change timestamps to you actual dates
```
PUT test-1
{
  "mappings": {
    "properties": {
      "@timestamp": {"type": "date"},
      "host.name": { "type": "keyword" }
    }
  }
}

PUT auditbeat-1
{
  "mappings": {
    "properties": {
      "@timestamp": {"type": "date"},
      "host.name": { "type": "boolean" }
    }
  }
}

POST auditbeat-1/_doc
{
  "@timestamp": 1714121723789,
  "host.name":"host 11",
  "user.name": "123"
}

POST test-1/_doc
{
  "@timestamp": 1714121723789,
  "host.name":"host 11",
  "user.name": "123"
}

```

- Create a query rule, with index pattern `test-1` and the query: '*'.
Wait for the alert to be generated
- Go to the Alerts page (not from the Rule, but all alerts)
- Click add exception from the alert and observe that it says that
fields have conflict about auditbeat index. Which is incorrect as a rule
has only `test-1` index pattern.
- Check all checkboxes about closing alerts and creating exceptions. See
that there is no success toast, and the rule also has no exception.
- Open flyout exception again. Observe that there is no more message
about conflicts. If you create an exception it will be successful.

https://github.com/elastic/kibana/assets/7609147/d29981f7-5d6f-41b2-af46-2ade884e3563

### Reason

In the `AddExceptionFlyout` we do have this line

```
 const { isLoading, indexPatterns, getExtendedFields } = useFetchIndexPatterns(rules);
```

From `AlertContextMenuComponent` we are passing try to load the rule
info and first past `undefined` to rules and then some real info.

The problem is that in the `useFetchIndexPatterns` - if rules not
defined, we return `getExtendedFields` related to the default data view,
but no there rule index pattern.

And probably there some race conditions happen, and after we pass rules
props, exceptions don't rerender the info.

As a fix for this BC I just wait for rule info to be loaded, and then
render exception flyout, but it only masks the problem.

As we want to fix this bug faster, it's probably ok to merge it like
that. And there will be an issue to address this later.

---------

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
(cherry picked from commit 4aabce5)

… (#182286)

# Backport

This will backport the following commits from `main` to `8.14`:
- [Don't render exceptions flyout if data is loading
(#181588)](#181588)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Khristinin
Nikita","email":"nikita.khristinin@elastic.co"},"sourceCommit":{"committedDate":"2024-05-01T18:58:38Z","message":"Don't
render exceptions flyout if data is loading (#181588)\n\n## Exceptions
not created for mappings with conflicts\r\n\r\nrelated:
https://github.com/elastic/kibana/pull/177007\r\n\r\n\r\nHow to
reproduce\r\n\r\n- Execute request in order, and change timestamps to
you actual dates\r\n```\r\nPUT test-1\r\n{\r\n \"mappings\": {\r\n
\"properties\": {\r\n \"@timestamp\": {\"type\": \"date\"},\r\n
\"host.name\": { \"type\": \"keyword\" }\r\n }\r\n }\r\n}\r\n\r\nPUT
auditbeat-1\r\n{\r\n \"mappings\": {\r\n \"properties\": {\r\n
\"@timestamp\": {\"type\": \"date\"},\r\n \"host.name\": { \"type\":
\"boolean\" }\r\n }\r\n }\r\n}\r\n\r\nPOST auditbeat-1/_doc\r\n{\r\n
\"@timestamp\": 1714121723789,\r\n \"host.name\":\"host 11\",\r\n
\"user.name\": \"123\"\r\n}\r\n\r\nPOST test-1/_doc\r\n{\r\n
\"@timestamp\": 1714121723789,\r\n \"host.name\":\"host 11\",\r\n
\"user.name\": \"123\"\r\n}\r\n\r\n```\r\n\r\n- Create a query rule,
with index pattern `test-1` and the query: '*'.\r\nWait for the alert to
be generated\r\n- Go to the Alerts page (not from the Rule, but all
alerts)\r\n- Click add exception from the alert and observe that it says
that\r\nfields have conflict about auditbeat index. Which is incorrect
as a rule\r\nhas only `test-1` index pattern.\r\n- Check all checkboxes
about closing alerts and creating exceptions. See\r\nthat there is no
success toast, and the rule also has no exception.\r\n- Open flyout
exception again. Observe that there is no more message\r\nabout
conflicts. If you create an exception it will be
successful.\r\n\r\n\r\n\r\n\r\nhttps://github.com/elastic/kibana/assets/7609147/d29981f7-5d6f-41b2-af46-2ade884e3563\r\n\r\n\r\n###
Reason\r\n\r\nIn the `AddExceptionFlyout` we do have this
line\r\n\r\n```\r\n const { isLoading, indexPatterns, getExtendedFields
} = useFetchIndexPatterns(rules);\r\n```\r\n\r\nFrom
`AlertContextMenuComponent` we are passing try to load the rule\r\ninfo
and first past `undefined` to rules and then some real info.\r\n\r\nThe
problem is that in the `useFetchIndexPatterns` - if rules
not\r\ndefined, we return `getExtendedFields` related to the default
data view,\r\nbut no there rule index pattern.\r\n\r\nAnd probably there
some race conditions happen, and after we pass rules\r\nprops,
exceptions don't rerender the info.\r\n\r\nAs a fix for this BC I just
wait for rule info to be loaded, and then\r\nrender exception flyout,
but it only masks the problem.\r\n\r\nAs we want to fix this bug faster,
it's probably ok to merge it like\r\nthat. And there will be an issue to
address this later.\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana
Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"4aabce5bcd9aa625c85af3f7dde9bc3b675d5344","branchLabelMapping":{"^v8.15.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport:prev-minor","v8.15.0"],"title":"Don't
render exceptions flyout if data is
loading","number":181588,"url":"https://github.com/elastic/kibana/pull/181588","mergeCommit":{"message":"Don't
render exceptions flyout if data is loading (#181588)\n\n## Exceptions
not created for mappings with conflicts\r\n\r\nrelated:
https://github.com/elastic/kibana/pull/177007\r\n\r\n\r\nHow to
reproduce\r\n\r\n- Execute request in order, and change timestamps to
you actual dates\r\n```\r\nPUT test-1\r\n{\r\n \"mappings\": {\r\n
\"properties\": {\r\n \"@timestamp\": {\"type\": \"date\"},\r\n
\"host.name\": { \"type\": \"keyword\" }\r\n }\r\n }\r\n}\r\n\r\nPUT
auditbeat-1\r\n{\r\n \"mappings\": {\r\n \"properties\": {\r\n
\"@timestamp\": {\"type\": \"date\"},\r\n \"host.name\": { \"type\":
\"boolean\" }\r\n }\r\n }\r\n}\r\n\r\nPOST auditbeat-1/_doc\r\n{\r\n
\"@timestamp\": 1714121723789,\r\n \"host.name\":\"host 11\",\r\n
\"user.name\": \"123\"\r\n}\r\n\r\nPOST test-1/_doc\r\n{\r\n
\"@timestamp\": 1714121723789,\r\n \"host.name\":\"host 11\",\r\n
\"user.name\": \"123\"\r\n}\r\n\r\n```\r\n\r\n- Create a query rule,
with index pattern `test-1` and the query: '*'.\r\nWait for the alert to
be generated\r\n- Go to the Alerts page (not from the Rule, but all
alerts)\r\n- Click add exception from the alert and observe that it says
that\r\nfields have conflict about auditbeat index. Which is incorrect
as a rule\r\nhas only `test-1` index pattern.\r\n- Check all checkboxes
about closing alerts and creating exceptions. See\r\nthat there is no
success toast, and the rule also has no exception.\r\n- Open flyout
exception again. Observe that there is no more message\r\nabout
conflicts. If you create an exception it will be
successful.\r\n\r\n\r\n\r\n\r\nhttps://github.com/elastic/kibana/assets/7609147/d29981f7-5d6f-41b2-af46-2ade884e3563\r\n\r\n\r\n###
Reason\r\n\r\nIn the `AddExceptionFlyout` we do have this
line\r\n\r\n```\r\n const { isLoading, indexPatterns, getExtendedFields
} = useFetchIndexPatterns(rules);\r\n```\r\n\r\nFrom
`AlertContextMenuComponent` we are passing try to load the rule\r\ninfo
and first past `undefined` to rules and then some real info.\r\n\r\nThe
problem is that in the `useFetchIndexPatterns` - if rules
not\r\ndefined, we return `getExtendedFields` related to the default
data view,\r\nbut no there rule index pattern.\r\n\r\nAnd probably there
some race conditions happen, and after we pass rules\r\nprops,
exceptions don't rerender the info.\r\n\r\nAs a fix for this BC I just
wait for rule info to be loaded, and then\r\nrender exception flyout,
but it only masks the problem.\r\n\r\nAs we want to fix this bug faster,
it's probably ok to merge it like\r\nthat. And there will be an issue to
address this later.\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana
Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"4aabce5bcd9aa625c85af3f7dde9bc3b675d5344"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.15.0","branchLabelMappingKey":"^v8.15.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/181588","number":181588,"mergeCommit":{"message":"Don't
render exceptions flyout if data is loading (#181588)\n\n## Exceptions
not created for mappings with conflicts\r\n\r\nrelated:
https://github.com/elastic/kibana/pull/177007\r\n\r\n\r\nHow to
reproduce\r\n\r\n- Execute request in order, and change timestamps to
you actual dates\r\n```\r\nPUT test-1\r\n{\r\n \"mappings\": {\r\n
\"properties\": {\r\n \"@timestamp\": {\"type\": \"date\"},\r\n
\"host.name\": { \"type\": \"keyword\" }\r\n }\r\n }\r\n}\r\n\r\nPUT
auditbeat-1\r\n{\r\n \"mappings\": {\r\n \"properties\": {\r\n
\"@timestamp\": {\"type\": \"date\"},\r\n \"host.name\": { \"type\":
\"boolean\" }\r\n }\r\n }\r\n}\r\n\r\nPOST auditbeat-1/_doc\r\n{\r\n
\"@timestamp\": 1714121723789,\r\n \"host.name\":\"host 11\",\r\n
\"user.name\": \"123\"\r\n}\r\n\r\nPOST test-1/_doc\r\n{\r\n
\"@timestamp\": 1714121723789,\r\n \"host.name\":\"host 11\",\r\n
\"user.name\": \"123\"\r\n}\r\n\r\n```\r\n\r\n- Create a query rule,
with index pattern `test-1` and the query: '*'.\r\nWait for the alert to
be generated\r\n- Go to the Alerts page (not from the Rule, but all
alerts)\r\n- Click add exception from the alert and observe that it says
that\r\nfields have conflict about auditbeat index. Which is incorrect
as a rule\r\nhas only `test-1` index pattern.\r\n- Check all checkboxes
about closing alerts and creating exceptions. See\r\nthat there is no
success toast, and the rule also has no exception.\r\n- Open flyout
exception again. Observe that there is no more message\r\nabout
conflicts. If you create an exception it will be
successful.\r\n\r\n\r\n\r\n\r\nhttps://github.com/elastic/kibana/assets/7609147/d29981f7-5d6f-41b2-af46-2ade884e3563\r\n\r\n\r\n###
Reason\r\n\r\nIn the `AddExceptionFlyout` we do have this
line\r\n\r\n```\r\n const { isLoading, indexPatterns, getExtendedFields
} = useFetchIndexPatterns(rules);\r\n```\r\n\r\nFrom
`AlertContextMenuComponent` we are passing try to load the rule\r\ninfo
and first past `undefined` to rules and then some real info.\r\n\r\nThe
problem is that in the `useFetchIndexPatterns` - if rules
not\r\ndefined, we return `getExtendedFields` related to the default
data view,\r\nbut no there rule index pattern.\r\n\r\nAnd probably there
some race conditions happen, and after we pass rules\r\nprops,
exceptions don't rerender the info.\r\n\r\nAs a fix for this BC I just
wait for rule info to be loaded, and then\r\nrender exception flyout,
but it only masks the problem.\r\n\r\nAs we want to fix this bug faster,
it's probably ok to merge it like\r\nthat. And there will be an issue to
address this later.\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana
Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"4aabce5bcd9aa625c85af3f7dde9bc3b675d5344"}}]}]
BACKPORT-->

Co-authored-by: Khristinin Nikita <nikita.khristinin@elastic.co>