## Summary
[dependency-cruiser](https://github.com/sverweij/dependency-cruiser/tree/main)
is used for building dependency graph.
### Show all dependencies for a specific package/plugin or directory
#### Run for all plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins -o ./tmp/deps-result-all.json
```
#### Run for single plugin
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -o ./tmp/deps-result-single.json
```
#### Run for multiple plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution x-pack/plugins/security -o ./tmp/deps-result-multiple.json
```
#### Run for `x-pack/packages`
```bash
bash scripts/dependency_usage.sh -p x-pack/packages -o ./tmp/deps-packages-1.json
```
#### Run for `packages`
```bash
bash scripts/dependency_usage.sh -p packages -o ./tmp/deps-packages-2.json
```
#### Benchmark
| Analysis | Real Time | User Time | Sys Time |
|-----------------------|-------------|-------------|------------|
| All plugins | 7m 21.126s | 7m 53.099s | 20.581s |
| Single plugin | 31.360s | 45.352s | 2.208s |
| Multiple plugins | 36.403s | 50.563s | 2.814s |
| x-pack/packages | 6.638s | 12.646s | 0.654s |
| packages | 25.744s | 39.073s | 2.191s |
#### Show all packages/plugins within a directory that use a specific
dependency
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins/security_solution
```
---
#### Show all packages/plugins within a directory grouped by code owner
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins -g owner
```
---
#### Group by code owner with adjustable collapse depth for fine-grained
grouping
**Fine-grained grouping**:
```sh
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 4
```
**Collapsed grouping**: groups the results under a higher-level owner
(e.g., `security_solution` as a single group).
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 1
```
---
#### Show all dependencies matching a pattern (e.g., `react-*`) within a
package
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -d 'react-*' -o ./tmp/result.json
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
__Related: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR filters the fields containing `@` in date type from `script`
processor.
## Before this PR
```json
{
"script": {
"tag": "script_convert_array_to_string",
"description": "Ensures the date processor does not receive an array value.",
"lang": "painless",
"source": "if (ctx.varonis?.varonis_alerts?.@timestamp != null &&\n ctx.varonis.varonis_alerts.@timestamp instanceof ArrayList){\n ctx.varonis.varonis_alerts.@timestamp = ctx.varonis.varonis_alerts.@timestamp[0];\n}\n"
}
},
{
"date": {
"if": "ctx.varonis?.varonis_alerts?.@timestamp != null",
"tag": "date_processor_varonis.varonis_alerts.@timestamp",
"field": "varonis.varonis_alerts.@timestamp",
"target_field": "event.start",
"formats": [
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'",
"ISO8601"
]
}
},
```
## After this PR
```json
"date": {
"if": "ctx.varonis?.varonis_alerts?.@timestamp != null",
"tag": "date_processor_varonis.varonis_alerts.@timestamp",
"field": "varonis.varonis_alerts.@timestamp",
"target_field": "event.start",
"formats": [
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'",
"ISO8601"
]
}
},
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
Closes#201346
This PR adds a `dat` dev script, which lets you easily run APM
deployment-agnostic tests, as we already do with `api` tests.
## Examples
Run only server with stateful config
```sh
node x-pack/plugins/observability_solution/apm/scripts/test/dat --stateful --server
```
Run only runner with stateful config
```sh
node x-pack/plugins/observability_solution/apm/scripts/test/dat --stateful --runner
```
Run everything with serverless config
```sh
node x-pack/plugins/observability_solution/apm/scripts/test/dat --serverless
```
More information
[here](https://github.com/elastic/kibana/pull/201351/files#diff-5ca943bbe3962fc31cce510407cc1563a959b0fdb9cb52619f57e1f182a9751a)
---------
Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/201531
This PR skips `Transaction groups alerts when data is loaded with avg
transaction duration alerts returns the correct number of alert counts`,
which is inside
`x-pack/test/api_integration/deployment_agnostic/apis/observability/apm/transactions/transactions_groups_alerts.spec.ts`
file, as it's failing on MKI.
Closes https://github.com/elastic/kibana/issues/200769
## Summary
This PR is a follow-up to https://github.com/elastic/kibana/pull/199854
and it adds the following code improvements:
- Replaces Mappings-editor-context-level property `hasEnterpriceLicense`
with plugin-context-level `canUseSyntheticSource` property
- Adds jest tests to check if the synthetic option is correctly
displayed based on license
- Improves readability of serializer logic for the source field
**How to test:**
The same test instructions from
https://github.com/elastic/kibana/pull/199854 can be followed with a
focus on checking that the synthetic option is only available in
Enterprise license.
Resolves#199751
## Summary
Use Fleet's default data output when onboarding integrations using
auto-detect flow.
## Screenshot
### Fleet output settings
<img width="1411" alt="Screenshot 2024-11-21 at 15 10 24"
src="https://github.com/user-attachments/assets/ac193552-7f18-4566-a84b-061df45c13f3">
### Generated Agent config
```
$ cat /Library/Elastic/Agent/elastic-agent.yml
outputs:
default:
type: elasticsearch
hosts:
- https://192.168.1.73:9200
ssl.ca_trusted_fingerprint: c48c98cdf7f85d7cc29f834704011c1002b5251d594fc0bb08e6177544fe304a
api_key: b1BkR1Q1TUIyOUpfMWhaS2NCUXA6SS1Jb3dncGVReVNpcEdzOGpSVmlzQQ==
preset: balanced
```
## Testing
1. Go to Fleet > Settings > Outputs
2. Edit the default output and enter dummy data into the "Elasticsearch
CA trusted fingerprint" field
3. Go through the auto-detect onboarding flow
4. Inspect the `elastic-agent.yml` file written to disk. It should
contain the default output configured in Fleet including
`ca_trusted_fingerprint` setting
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Currently, the partitionPatchRequest in
x-pack/plugins/cases/server/client/cases/bulk_update.ts will not check a
case properly if a case is being re-opened, instead of an else if in the
loop comparing cases to cases in the request, the status logic should be
outside of this set of if statements. If a case is being re-opened, the
final else is never run, and casesToAuthorize is 0. This results in
ensureAuthorized being called with an empty array of entities, and so
the check always succeeds. To fix this, reopenedCases is still populated
in the same loop, just not when casesToAuthorize logic is running as
well. Also adds some missing tests for this and the create comment
permission as requested in
https://github.com/elastic/kibana/pull/194898.
### 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
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Part of #193245
Related #200226Closes#200743
## Summary
This PR completes the migration of remaining Service Overview tests to
the Deployment Agnostic test framework. In this PR, one test was
deduplicated (the Dependencies test), and the Instances Detailed
Statistics cases dealing with archiver data was migrated to make use of
synthtrace instead. Snapshots included were redone to match the data
generated by synthtrace, but no other cases were changed to ensure the
new migrated tests were passing the same assumptions as before.
## How to Test
### Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt/apm.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.apm.serverless.config.ts
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
### Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.apm.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.apm.stateful.config.ts
```
---------
Co-authored-by: jennypavlova <jennypavlova94@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/193352
Update:
Using a new SO field `bump_agent_policy_revision` in package policy type
to mark package policies for update, this will trigger an agent policy
revision bump.
The feature supports both legacy and new package policy SO types, and
queries policies from all spaces.
To test, add a model version change to the package policy type and save.
After Fleet setup is run, the agent policies using the package policies
should be bumped and deployed.
The same effect can be achieved by manually updating a package policy SO
and loading Fleet UI to trigger setup.
```
'2': {
changes: [
{
type: 'data_backfill',
backfillFn: (doc) => {
return { attributes: { ...doc.attributes, bump_agent_policy_revision: true } };
},
},
],
},
curl -sk -XPOST --user fleet_superuser:password -H 'content-type:application/json' \ -H'x-elastic-product-origin:fleet' \
http://localhost:9200/.kibana_ingest/_update_by_query -d '
{ "query": {
"match": {
"type": "fleet-package-policies"
}
},"script": {
"source": "ctx._source[\"fleet-package-policies\"].bump_agent_policy_revision = true",
"lang": "painless"
}
}'
```
```
[2024-11-20T14:40:30.064+01:00][INFO ][plugins.fleet] Found 1 package policies that need agent policy revision bump
[2024-11-20T14:40:31.933+01:00][DEBUG][plugins.fleet] Updated 1 package policies in space space1 in 1869ms, bump 1 agent policies
[2024-11-20T14:40:35.056+01:00][DEBUG][plugins.fleet] Deploying 1 policies
[2024-11-20T14:40:35.493+01:00][DEBUG][plugins.fleet] Deploying policies: 7f108cf2-4cf0-4a11-8df4-fc69d00a3484:10
```
TODO:
- the same flag has to be added on agent policy and output types, and
the task extended to update them
- I plan to do this in another pr, so that this doesn't become too big
- add integration test if possible
### Scale testing
Tested with 500 agent policies split to 2 spaces, 1 integration per
policy and bumping the flag in a new saved object model version, the
bump task took about 6s.
The deploy policies step is async, took about 30s.
```
[2024-11-20T15:53:55.628+01:00][INFO ][plugins.fleet] Found 501 package policies that need agent policy revision bump
[2024-11-20T15:53:57.881+01:00][DEBUG][plugins.fleet] Updated 250 package policies in space space1 in 2253ms, bump 250 agent policies
[2024-11-20T15:53:59.926+01:00][DEBUG][plugins.fleet] Updated 251 package policies in space default in 4298ms, bump 251 agent policies
[2024-11-20T15:54:01.186+01:00][DEBUG][plugins.fleet] Deploying 250 policies
[2024-11-20T15:54:29.989+01:00][DEBUG][plugins.fleet] Deploying policies: test-policy-space1-1:4, ...
[2024-11-20T15:54:33.538+01:00][DEBUG][plugins.fleet] Deploying policies: policy-elastic-agent-on-cloud:4, test-policy-default-1:4, ...
```
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/200858
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Assign test files to security-defend-workflows team
Contributes to: #192979
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to platform-security team
Contributes to: #192979
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR enables data_usage plugin for Serverless environment for all 3
solutions.
To manage feature availability added feature flag, which is turning Data
Usage off by default.
## Summary
This PR stabilizes the inference endpoint serverless earch UI tests for
MKI runs by waiting for loading to finish after refreshing the page.
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `32099b9` ->
`55b297d` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Adds a bunch of UX updates based on the feedback after demo.
- [x] Tidy chart legend action popup and links
- [x] fix UX date picker invalid time (UX shows invalid time falsely)
- [ ] Tooltip for date filter
- [ ] send UTC time to requests (1:1 mapping for date-time picked vs
date-time sent)
- [x] Remove unusable common date filter shortcuts
- [x] data stream filter `select all`
- [x] data stream filter `clear all`
- [x] No charts empty state
- [x] filter in datastreams that have greater than `0` bytes storage
size
- [ ] Filter out system indices from data stream filter?
- [x] Taller filter popover list for larger lists
Follow up of https://github.com/elastic/kibana/pull/200731
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_node:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
When formatting elasticsearch responses for the frontend, the timelines
search strategies will treat unmapped fields as type: keyword. If the
underlying field is actually an object, but is seen as a string in the
code, this for (key in source) loop will fail, as it's trying to loop
over a string. Fix below should have minimal effect as the data is
accessible at the further nested keys.
### 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
Closes: #199760
Popovers, dialogs which are accessible with mouse, should also be
accessible with keyboard. Otherwise users using only keyboard will miss
the information present in popover, dialog.
Closes: #199749
User reaches the same button two times when navigating using only
keyboard and it can get confusing. Better for element to get focus only
one time when navigating in sequence from one element to another and for
the user only to hear one announcement of the element.
## What was changed:
1. `CreateSearchApplicationButton` component:
- `EuiPopover` was replaced to more a11y-friendly `EuiToolTip`
- extra `div` element with `tabindex` was removed.
## Screen
https://github.com/user-attachments/assets/fbb62841-6f2f-45d0-bee3-39a11a4fc777
## Summary
This PR:
- Enables Inference Management in ES3
- Fixes small issues to make sure it works in ES3.
- Added FTR tests.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [X] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [X] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_node:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
For most of 8.x, both anecdotally from users and in development,
timeline search strategy based apis would often seem slower than the
equivalent search in discover or elsewhere in kibana, and I have long
suspected that this came from how the timeline sever code formatted the
elasticsearch responses for use in the UI, and while working on
something else, noticed even higher than normal occurrences in logs of
"][http.server.Kibana] Event loop utilization for
/internal/search/timelineSearchStrategy exceeded threshold of..." and so
I tried to refactor all of the functions in place as much as possible,
keeping the apis similar, most of the unit tests, etc, but removing as
many as possible of the Promise.alls, reduce within reduce, etc. This
has lead to a substantial improvement in performance, as you can see
below, and with larger result sets, I think the difference would only be
more noticeable.
After fix:
~40 ms for formatTimelineData with ~1000 docs
<img width="1470" alt="image"
src="https://github.com/user-attachments/assets/c664f940-aa37-4335-9204-2a9300fbafa0">
Before fix:
~18000 ms for formatTimelineData with ~1000 docs
<img width="1464" alt="image"
src="https://github.com/user-attachments/assets/124fa327-13b9-41ef-9489-8d27f853590c">
[chrome_profile_timeline_slow.cpuprofile](https://github.com/user-attachments/files/17825602/chrome_profile_timeline_slow.cpuprofile)
[chrome_profile_timeline_fast.cpuprofile](https://github.com/user-attachments/files/17825606/chrome_profile_timeline_fast.cpuprofile)
I've attached the chrome devtools profiles for each, the time was
measured with the function:
```
async function measureAwait<T>(promise: Promise<T>, label: string): Promise<T> {
const start = performance.now();
try {
const result = await promise;
const duration = performance.now() - start;
console.log(`${label} took ${duration}ms`);
return result;
} catch (error) {
const duration = performance.now() - start;
console.log(`${label} failed after ${duration}ms`);
throw error;
}
}
```
Wrapped around the call to formatTimelineData in
x-pack/plugins/timelines/server/search_strategy/timeline/factory/events/all/index.ts
### Checklist
- [ ] [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
In this PR, I'm fixing a bug where the task manager unhealthy logs were
showing the wrong reason. Because the if condition was checking
`assumedAverageRecurringRequiredThroughputPerMinutePerKibana` to be less
than `capacityPerMinutePerKibana`, it would log this as the reason task
manager is healthy. However whenever the value is less, it means task
manager is running fine from a recurring task perspective. Changing the
if condition allows the next step in the code to log which then logs
`assumedRequiredThroughputPerMinutePerKibana` as the real reason why
task manager is unhealthy.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix an issue with auto-recovery of Knowledge Base setup.
When the KB setup was initialized on an undersized cluster, the model
failed to deploy correctly. This resulted in the KB ending up in a
broken state, repeatedly displaying the Setup KB button.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR updates the `cleanMlIndices` service method to no longer run
with `esDeleteAllIndices` and thus no longer requires system index
superuser privileges.
### Details / other changes
- Not all ML items can be cleaned up through APIs (e.g. notifications),
so tests have been adjusted to deal with pre-existing data
- Some cleanup steps had to be re-ordered
- Basic license tests didn't need the `cleanMlIndices` in their `before`
so it was removed there
- Observability serverless tests can't use `cleanMlIndices` as the APIs
for DFA are not available for that project type, so the cleanup is
changed to `cleanAnomalyDetection` for the AD tests and the
`cleanMlIndices` is removed from the AI assistant helpers as the
existing cleanup there should be enough
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
## Summary
Removed `security` property from `route.options` types, `security`
should exist only as a top level property.
Fixed routes with incorrect config accordingly.
## Routes Impacted
Routes with disabled authorization (impact can be considered negligible)
```
/internal/entities/managed/enablement
/internal/entities/managed/enablement
/internal/entities/managed/enablement
/internal/entities/definition
/internal/entities/definition/{id}
/internal/entities/definition/{id?}
/internal/entities/definition/{id}/_reset
/internal/entities/definition/{id}
/api/streams/_enable
/api/streams/_resync
/api/streams/{id}/_fork
/api/streams/{id}
/api/streams/{id}
/api/streams/{id}
/api/streams
```
Routes with authorization (will be backported to `8.17.0`)
```
/internal/product_doc_base/status
/internal/product_doc_base/install
/internal/product_doc_base/uninstall
```
__Fixes: https://github.com/elastic/kibana/issues/201347__
