* [Logs UI][Metrics UI] Remove deprecated config fields from APIs
* Fix typecheck
* Fix typecheck
* Fix typecheck
* Fix jest
* Fix functional test
* Remove extraneous timeField args
* Typecheck fix
* Consolidate log file changes to ResolvedLogSourceConfiguration
* Fix merge
* Revert additional logs files
* Revert inventory models
* Revert log_analysis api
* Fix timefield reference in process list
* Restore logs page files, fix typecheck on mock
* Fix functional test
* Restore inventory models index
* Fix typecheck on getFilteredMetrics
* Look CI if you don't tell me all the type errors at once I can't fix them all
* Maybe this is the last typecheck fix who knows
* Add compatibility aliases to alerts as data indices
* Fix dupe mitigation, allow more fields in mapping
* Remove legacy signals fields from new RAC alerts
* Fix cypress test
* Remove outdated comment
* Reduce flakiness in time based test
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Add `.catch()` statement to ES calls in order to get better stacktraces
* Improve efficiency of getHostEndpoint() search strategy method
* Refactor `getHostEndpoint()` to use new Metadata service as well as the internal kibana ES client
* unskip test suite
* Fix functional tests and some refactoring
* Refactor Policy Details test and centralize getting of Agent Policy combined input for endpoint
* Change approach for checking policy data in fleet pages
* Change Policy Settings displayed in Fleet to a) show a loader while retrieving settings and b) show loading errors if any
* Close any visible toasts before clicking on the save button
Concurrency parameters were not in the correct place which made concurrency settings not in effect.
Moved it to to performance.sh step which also has parallelism in the same level.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds console logging and relaxes a few 200 checks in the end to end tests in two areas of:
* createExceptionListItem
* importFile
As recently the tests are failing around these parts and possibly we can get information on the next failures if it is from these two areas or if it's from somewhere else we are not expecting.
Also outputs the body message so if it fails in these areas we can see the message with the conflict that might help us see where the issue is arising.
### Checklist
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
* remove use of boom from info response handler; also changed unauthd response to forbidden to avoid client logging user out
* rather return 500 with err.message
* added jest tests for common cases on the info route
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This PR removes the `monitor` cluster privilege from the `ft_ml_ui_extras` test role as it's no longer required by the categorization wizard and we want to stay close to the minimum set of required privileges for our test users.
* [ILM] Fixed ILM a11y test by creating a snapshot repo that is now required in the ILM API
* [ILM] Fixed functional test by creating a snapshot repository
* [ILM] Updated the params after es client update
* [ILM] Added filtering by policy name to the a11y test to find the correct ILM policy in the list
* [ILM] Added filtering by policy name to the a11y test to find the correct ILM policy in the list
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [ML] Retain _meta on clone
* [ML] Fix validation on schema to only check it it's defined/not null
* [ML] Remove validation because es should handle the validation already
* Change type to unknown
## Summary
* For the test of `create_endpoint_exceptions.ts` code was changed to try to reduce/remove flake. I put the code back to where it was and with the sorting introduced it all should pass
* Added `await waitForSignalsToBePresent(supertest, 1, [id]);` to areas of code that were missing.
* The `.flat` should be an added layer of protection for flakes.
### Checklist
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
## Summary
Fixes flake tests of:
https://github.com/elastic/kibana/issues/115918https://github.com/elastic/kibana/issues/103273https://github.com/elastic/kibana/issues/108640https://github.com/elastic/kibana/issues/109447https://github.com/elastic/kibana/issues/100630https://github.com/elastic/kibana/issues/94535https://github.com/elastic/kibana/issues/104260
Security solution has been using `bsearch` and has encountered flake in various forms. Different developers have been fixing the flake in a few odd ways (myself included) which aren't 100%. This PR introduces a once-in-for-all REST API retry service called `bsearch` which will query `bsearch` and if `bsearch` is not completed because of async occurring due to slower CI runtimes it will continuously call into the `bsearch` with the correct API to ensure it gets a complete response before returning.
## Usage
Anyone can use this service like so:
```ts
const bsearch = getService('bsearch');
const response = await bsearch.send<MyType>({
supertest,
options: {
defaultIndex: ['large_volume_dns_data'],
}
strategy: 'securitySolutionSearchStrategy',
});
```
If you're using a custom auth then you can set that beforehand like so:
```ts
const bsearch = getService('bsearch');
const supertestWithoutAuth = getService('supertestWithoutAuth');
const supertest supertestWithoutAuth.auth(username, password);
const response = await bsearch.send<MyType>({
supertest,
options: {
defaultIndex: ['large_volume_dns_data'],
}
strategy: 'securitySolutionSearchStrategy',
});
```
## Misconceptions in the tests leading to flake
* Can you just call the bsearch REST API and it will always return data first time? Not always true, as when CI slows down or data increases `bsearch` will give you back an async reference and then your test will blow up.
* Can we wrap the REST API in `retry` to fix the flake? Not always but mostly true, as when CI slows down or data increases `bsearch` could return the async version continuously which could then fail your test. It's also tedious to tell everyone in code reviews to wrap everything in `retry` instead of just fixing it with a service as well as inform new people why we are constantly wrapping these tests in `retry`.
* Can we manually parse the `bsearch` if it has `async` for each test? This is true but is error prone and I did this for one test and it's ugly and I had issues as I have to wrap 2 things in `retry` and test several conditions. Also it's harder for people to read the tests rather than just reading there is a service call. Also people in code reviews missed where I had bugs with it. Also lots of boiler plate.
* Can we just increase the timeout with `wait_for_completion_timeout` and the tests will pass for sure then? Not true today but maybe true later, as this hasn't been added as plumbing yet. See this [open ticket](https://github.com/elastic/kibana/issues/107241). Even if it is and we increase the timeout to a very large number bsearch might return with an `async` or you might want to test the `async` path. Either way, if/when we add the ability we can increase it within 1 spot which is this service for everyone rather than going to each individual test to add it. If/when it's added if people don't use the bsearch service we can remove it later if we find this is deterministic enough and no one wants to test bsearch features with their strategies down the road.
## Manual test of bsearch service
If you want to manually watch the bsearch operate as if the CI system is running slow or to cause an `async` manually you manually modify this setting here:
https://github.com/elastic/kibana/blob/master/src/plugins/data/server/search/strategies/ese_search/request_utils.ts#L61
To be of a lower number such as `1ms` and then you will see it enter the `async` code within `bsearch` consistently
## Reference PRs
We cannot set the wait_for_complete just yet
https://github.com/elastic/kibana/issues/107241 so we decided this was the best way to reduce flake for testing for now.
### Checklist
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
