[ResponseOps][Alerts] Migrate alerts fetching to TanStack Query

[umbopepato]

Summary

Implements a new useSearchAlertsQuery hook based on TanStack Query to replace the useFetchAlerts hook, following this organizational logic.

This PR focuses mainly on the fetching logic itself, leaving the surrounding API surface mostly unchanged since it will be likely addressed in subsequent PRs.

To verify

1. Create rules that fire alerts in different solutions
2. Check that the alerts table usages work correctly ({O11y, Security, Stack} alerts and rule details pages, ...)
   1. Check that the alerts displayed in the table are coherent with the solution, KQL query, time filter, pagination
   2. Check that pagination changes are reflected in the table
   3. Check that changing the query when in pages > 0 resets the pagination to the first page

Closes point 1 of #186448
Should fix #171738

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[umbopepato]

/ci

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[umbopepato]

Thanks for fixing the loader!

When I click on refresh, if the data is the same as before, the time Updated message does not change, is it the same for you?

Regarding pagination, I still see the issue, I will check to see if I can find a way to reproduce it.

Ok so it looks like the AlertsSearchBar only updates the query state on refresh. That triggers an actual refetch only if at least one of the parameters changes, which happens with sliding window time filters such as Last 24H. Ranges such as Today have fixed start and end dates (i.e. 59:59.999Z), which never cause the fetch alerts query key to change and thus a new request to start. This seems to be happening on main as well.

As for the Updated ... ago indicator, that's currently only connected to the bulk actions state so it doesn't reflect the timing of the alerts fetching (completing the migration to react-query is useful to show a better indication here based on all the queries used in the table).

The good news is this PR is useful to improve the "force refetch" functionality since we'll have tools like query's refetch and queryClient.invalidateQueries() so once this is merged we can work on exposing a more solid refresh API (perhaps through a new AlertsContext or an imperative handle on the AlertsTable).

cc @cnasikas

[JiaweiWu]

LGTM

[cnasikas]

Great work! Thanks for addressing my feedback.

[maryam-saeidi]

Ok so it looks like the AlertsSearchBar only updates the query state on refresh. That triggers an actual refetch only if at least one of the parameters changes, which happens with sliding window time filters such as Last 24H. Ranges such as Today have fixed start and end dates (i.e. 59:59.999Z), which never cause the fetch alerts query key to change and thus a new request to start. This seems to be happening on main as well.

I checked in edge-oblt, and you are right; when we have absolute time, the refresh button does not do anything, not sure if it is expected or not 🤔 (I will check how it works in other places and will create an issue if this needs to be fixed.)

As for the Updated ... ago indicator, that's currently only connected to the bulk actions state so it doesn't reflect the timing of the alerts fetching (completing the migration to react-query is useful to show a better indication here based on all the queries used in the table).

Is my understanding correct that this will be fixed when the bulk action is migrated to react-query? Does it make sense to hide it if it does not show the correct information, or will it be fixed before the v8.16 release?

The good news is this PR is useful to improve the "force refetch" functionality since we'll have tools like query's refetch and queryClient.invalidateQueries() so once this is merged we can work on exposing a more solid refresh API (perhaps through a new AlertsContext or an imperative handle on the AlertsTable).

That would be awesome!

[maryam-saeidi]

Update: Umbo and I checked the pagination issue, and it might be a feature :D I will double-check it with the Eui team.

Regarding Updated ... ago, Umbo has it in his TODO list, and it sometimes does not work if the number of alerts does not change.

So overall, it LGTM! Thanks Umbo for doing this 🙌🏻

[logeekal]

Look great on behalf on @elastic/security-threat-hunting-investigations. I have desk tested below scenarios both on Alerts and Rule Details page. I have also asked a small question below regarding the failed test.

- Row Action
	- Update Alert Status
	- Add to Timeline.
- Bulk Actions
	- Update Alert Status
- Field Browser
	- Add Columns
	- Remove Columns
- Refresh Button
- Filter/Query
	- Adding a filter
	- Adding a KQL Query
	- Adding a Lucene Query
- Building block Filters.
- Inspect 
- Run Time fields

Warning

I encountered and error once on the Rule Details Page but my mistake I navigated away and did not take the screenshot. Additionally I cannot reproduce it again but I will keep an eye.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 3d6857c
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-186978-3d6857c5e622
• Observability Deployment

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
alerting	223	228	+5
observability	1059	1064	+5
securitySolution	5611	5616	+5
triggersActionsUi	802	806	+4
total			+19

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/alerting-types	191	199	+8
@kbn/alerts-ui-shared	284	293	+9
ruleRegistry	249	250	+1
total			+18

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
alerting	91.7KB	91.7KB	+11.0B
infra	1.5MB	1.5MB	+14.0B
observability	420.6KB	420.6KB	+65.0B
securitySolution	20.4MB	20.4MB	+11.0B
slo	878.4KB	878.4KB	+14.0B
triggersActionsUi	1.7MB	1.6MB	-3.4KB
total			-3.3KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
@kbn/alerts-ui-shared	8	9	+1
ruleRegistry	14	11	-3
triggersActionsUi	52	51	-1
total			-3

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
alerting	25.5KB	25.5KB	-2.0B
observability	101.8KB	101.9KB	+58.0B
triggersActionsUi	120.3KB	122.3KB	+2.0KB
total			+2.1KB

Unknown metric groups

API count

id	before	after	diff
@kbn/alerting-types	194	202	+8
@kbn/alerts-ui-shared	300	310	+10
ruleRegistry	286	287	+1
total			+19

History

• 💛 Build #223157 was flaky 4362489b0e3092ac4fbfe85b4e6a8e2d2b43fbeb
• 💔 Build #217956 failed 40a6699c5438aeec2438fdb107821bba976820b5
• 💔 Build #217894 failed d1f9f8e9c518c6f0f5dd316eef769c1a1d10a689

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream