## Summary
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The code changes in this PR ensure that the transform ID is limited to
36 characters when creating or updating the transform for risk-score.
This adjustment aligns with ES constraint on transform ID length.
## Test Steps
1. Create a new namespace with a very long name. Ex :
`namespace_that_stretches_farther_than_the_universe_and_beyond_like_buzz`
🚀
2. Enable the Risk Score in the new namespace. It should successfully
get enabled.
3. Check the transform that was created (using dev tools)
```
GET _transform/risk_score_latest_transform_*?filter_path=transforms.id,transforms._meta.space_id
```
Output
### 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] 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] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
# Purpose
This change introduces new validations that ensure no loss of data is
possible if a user accidentally sets the Security Entity Store enrich
policy execution interval to a value that “doesn’t play nicely” with the
lookback period value.
The specific logic (greater than or equal to half the value) was chosen
to not only ensure no loss of data, but also provide extra resiliency in
case of a failed enrich policy execution.
(Note that this is not considered a breaking change, as the parameters
are not yet available on any version of Elastic, including Serverless.)
# How to test
1. Load appropriate entity log data to your Kibana instance (for
example, using the
[security-documents-generator](https://github.com/elastic/security-documents-generator))
2. Navigate to the Developer console
3. Attempt to enable the Entity Store via the /enable or /init routes
(examples below), and pass in values that are expected to error. For
example, “lookbackPeriod”: “24h” and “enrichPolicyExecutionInterval”:
“24h” should fail, because of the validation logic
4. Expect results similar to those shown below, specifically a 400
error, or else a success message
<img width="1902" alt="Screenshot 2025-02-27 at 12 57 45 AM"
src="https://github.com/user-attachments/assets/a7f4b0fb-9899-4e00-a0ae-d172245bd506"
/>
<img width="1909" alt="Screenshot 2025-02-27 at 12 58 06 AM"
src="https://github.com/user-attachments/assets/372acde2-9d7b-4c75-8596-af8374088f79"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
https://github.com/elastic/kibana/issues/209258 updates the settings
endpoint to also be able to get/set the alert deletion settings. The
alert deletion setting should make use of this new endpoint to load its
initial data and store any user update.
> [!WARNING]
> This will be merged into a feature branch.
## QA:
Activate the feature flag
```
# config/kibana.dev.yml
xpack.trigger_actions_ui.enableExperimental: ['alertDeletionSettingsEnabled']
```
Follow these steps:
- Go to rules
- Click on settings
- Change the alert deletion settings
- Click on save
- Reload and check the settings kept the values
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This pr fixes some odd issues with getBulkActions, which is really a
hook in disguise, as well as an issue with the useGetMutedAlertsQuery
hook, which was/is fetching data much more often than it should, exactly
why that is I'm not sure, perhaps something to do with how timeline
blocks focus to the underlying DOM when it's open, and this causes the
default to true refetchOnWindowFocus prop of useQuery to re-run the
query, or if there's an error with the queryKey.
Below are 2 GIFs comparing react performance profiles of simply opening
and then closing the timeline while on the alerts page with 50 alerts in
the table.
Before fix:
12 renders for a total of 950 ms, a large portion of which is coming
from the alert table cells.
After fix:
8 renders for a total of 380 ms, almost none of it coming from the alert
table.
Each of the alerts table and timeline/discover drive some of the more
stateful and complex workflows in kibana on their own, and on top of
that one is rendering within a flyout on top of the other, listening to
the same url changes/tens of context provider wrappers changing above
them in the tree/kibana services, etc, & so proper memoization is a
pre-requisite for a good ux.
### 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
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
Co-authored-by: Ashokaditya <ashokaditya@elastic.co>
Co-authored-by: Viduni Wickramarachchi <viduni.wickramarachchi@elastic.co>
## Summary
Addresses https://github.com/elastic/kibana/issues/209048
1. Started ES with
```
yarn es snapshot --version 8.19.0 --data-archive=../kibana/x-pack/test/upgrade_assistant_integration/fixtures/data_archives/upgrade_assistant.zip
```
2. Then created updated archive
```
zip -r ../../../kibana/x-pack/test/upgrade_assistant_integration/fixtures/data_archives/upgrade_assistant.zip data -x "*/\.*"
```
## Summary
Part of https://github.com/elastic/kibana/issues/208908
Replaces scss to css-in-js.
> [!NOTE]
> The rest of the `.scss` will be migrated in different pull requests
<!--
- [ ] `x-pack/platform/plugins/private/graph/`public/_mixins.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_app.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_graph.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_inspect.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_search_bar.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_search_bar.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/field_manager/_field_picker.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/field_manager/_index.scss
-->
### Checklist
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
### Fleet
- Exposed API route for bulk get package policies via the routes service
- Created and exposed type `BulkGetPackagePoliciesRequestBody`
<br/>
### Security Solution
The following changes were made to Endpoint Artifacts in support of
spaces:
> [!NOTE]
> Space awareness is currently behind feature flag:
`endpointManagementSpaceAwarenessEnabled`
- The policy assignment component, which is displayed on artifact's
Create and Update forms, now:
- Displays the count of policies (if any) that are associated with the
artifact, but not currently accessible in the active space (screen
capture 1️⃣ )
- When a user does NOT have the Global Artifact privilege, the `Global`
toggle selection will be disabled and a tooltip is displayed. This
change also applies to the create form where the default selection will
be per-policy and the global button will be disabled. (screen capture
2️⃣ )
- Artifact policy assignments that are not accessible in active space
are preserved when submitting an update to the artifact
- The component was also refactored a bit to simplify its list of props
- Artifact card policy assignment menu was adjusted to show any policy
that is not accessible to the user as "disabled" along with a tooltip
(screen capture 3️⃣ )
- The update artifact API was changed (via server-side extension point)
to not error when validating policies that are not accessible in active
space if they were already associated with the item being updated.
- Fixes a bug in the Find artifacts API (impact only when spaces was
enabled) where an invalid filter was created when there was no policies
currently shared with active space.
## Summary
While doing a POC trying to implement the grouping component with the
UnifiedDataTable, I discovered a rendering issue that caused some sort
of infinite loop rerendering after selecting a group.
This PR fixes that issue but making sure we do not have a new instance
of an empty array every time the component is rendered.
## Summary
This PR reworks how APM handles getting its sources data, elevating the
necessary code to a private shared plugin so that Discover for Traces
can access the data and handle user provided configuration. It also
removes the need for Discover for Traces to rely on the APM static data
view, so the Trace data source and document profile will work on any
compatible/configured index, even in ESQL mode.
Closes#211414
<img alt="ESQL Discover Traces Screenshot 2025-03-04 173032"
src="https://github.com/user-attachments/assets/f5bbb736-8b8b-45dc-ac23-4bf7083aa47e"
/>
## How to test
Test with olbt-cli instance for now, will post for doing with synthtrace
data. Ensure the following is added to your kibana.dev.yml:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
```
- Make sure your space has the Observability solution view configured
- Go to Discover page
- Select Data Views mode if required and create a view with a `traces`
specific index. Or use the APM static data view.
- The default columns on the page should show the summary column with
four of the following badges: `service.name`, `event.outcome`,
`transaction.name`, `transaction.duration.us`, `span.name`,
`span.duration.us`
- Go to ESQL mode with the query targetting a `traces` index
- The default columns should show the same as in Data View mode
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Irene Blanco <irene.blanco@elastic.co>
## Summary
This PR fixes a regression introduced for user messages.
The `viewMode` check moved from observable to its raw value but still
performing the observable check.
The fix is to check both the panel `viewMode` AND as fallback the
embeddable hierarchy viewMode until the `edit` mode is met.
---------
Co-authored-by: Nick Partridge <nick.ryan.partridge@gmail.com>
## Summary
The PR updates the code to extend the lookback period for Risk scoring
calculations from `now-30m` to `now-30d`.
This change impacts:
- Risk score UI (date picker)
- The preview API
- The enable API (for Risk Score Saved Object configuration)
### 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] [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_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Screenshots :
## UI and Preview API payload
## Risk Engine configuration SO
## Testing Steps:
1. Navigate to the Entity Analytics management page (Entity Risk Score
webpage).
2. Ensure the default text in the date picker displays **"Last 30
days"**.
3. Open the **Network** tab in Developer Tools and verify that the
**"preview"** API request reflects a 30-day difference between the
`from` and `to` values.
4. If the **Risk Engine** is enabled, disable it and open a window
displaying Kibana logs.
5. Re-enable the **Risk Engine** and check the logs for the
configuration message: **"Risk engine running with configuration"**. The
expected range should be:
```json
"range": {
"start": "now/M",
"end": "now"
}
```
## Advanced Testing Steps
1. The date picker should default to **"Last 30 days"**. If you change
it to **"Yesterday"** without clicking **Save changes**, the **Preview
API** should reflect "Yesterday," but the **Saved Object (SO)** should
**not** update its range.
2. Upon refreshing the page without saving the changes, the date picker
should reset to its default value, **"Last 30 days"**.
Closes https://github.com/elastic/kibana/issues/208037
This change switches OTel K8S quickstart flow on Serverless to the
managed OTel collector as the ingest endpoint.
* Adds shared `useOtelIngestEndpointUrl` hook to be later re-used in
OTel Host flow as well
* Adds the logic to use APM API key on serverless to access the managed
service endpoint
* Modifies the code snipped with the new variables
## How to test
* Use the Serverless instance deployed from this PR, make sure OTel K8S
flow code snippet uses the managed service endpoint, ingest logs from
your computer (you can use [reference-stack
cluster](https://github.com/elastic/oblt-reference-stack) with minikube)
* Run the classic Kibana locally, and make sure the OTel K8S flow uses
the usual code snippet with ES ingest endpoint, ingest logs from your
computer
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR establishes the baseline to execute Cypress tests in the new
`search_ai_lake` tier.
## Changes Introduced
- All tests under
`x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc` will be
executed using the new tier by default.
- These tests will run as part of the PR process within the `Serverless
AI4DSOC - Security Solution Cypress Tests` execution.
## Adding a New Test
To add a new test, follow these guidelines:
- Read the
[README](x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc/README.md).
- Inside the `AI4DSOC` folder, we should have different subfolders
representing the various AI4DSOC functionalities.
- Each subfolder should have ownership by either an area team or the
developers actively working on it.
- Make sure that any functionality you want to be tested in the new tier
is added inside the `AI4DSOC` folder; otherwise, that functionality will
be tested using the complete tier.
## Running Tests Locally
Run the tests with the following Yarn scripts from
`x-pack/test/security_solution_cypress`:
```sh
yarn cypress:open:ai4dsoc:serverless
```
Opens the Cypress UI with all tests in the `e2e/ai4dsoc` directory. This
also runs a mocked serverless environment using the `ai_soc` product
line and `search_ai_lake` tier by default.
```sh
yarn cypress:run:ai4dsoc:serverless
```
Runs all tests tagged as @serverless in the e2e/ai4dsoc directory in
headless mode using the ai_soc product line and search_ai_lake tier by
default.
## Key Considerations
- All tests must have the `@serverless` tag to be executed as part of
the PR process.
- MKI is not yet supported for test execution.
- The AI4DSOC Cypress tests will be executed each time there is a change
in one of its
[dependencies](https://github.com/elastic/kibana/blob/main/.buildkite/scripts/pipelines/pull_request/pipeline.ts).
- All tests are executed by default using the `platform_engineer` role.
- Temporary Ownership: The Security Engineering Productivity team will
own the entire AI4DSOC testing folder initially to ensure structure and
best practices. Once all teams understand the workflow, this ownership
will be removed.
- Execution Time: If test execution in a PR takes more than 45 minutes,
parallelism should be increased in the new
`.buildkite/pipelines/pull_request/security_solution/ai4dsoc.yml` file.
## Security Engineering Productivity Codeownership Responsibilities
The Security Engineering Productivity team should ensure:
- Best practices are followed.
- All tests are placed inside a functionality subfolder.
- Each functionality subfolder has designated code owners.
- Tests include the `@serverless` label.
- The execution of AI4DSOC tests does not exceed 45 minutes.
## Follow-Up Tasks
- Remove the dummy test (@tomsonpl feel free to delete it when you need
to add new tests to the navigation).
- Integrate tests into the periodic pipeline.
- Add tests to the Kibana QA quality gate.
- Update the README with MKI instructions once tests are added to the
periodic pipeline and Kibana QA quality gate.
- Clarify which roles will be used for the AI4DSOC effort and update the
tests accordingly.
Adding a link to the stream into the overview tab of the discover
document flyout:
<img width="228" alt="Screenshot 2025-03-12 at 08 57 48"
src="https://github.com/user-attachments/assets/dfd396e7-b0dc-4cca-a09c-637357cc88f9"
/>
Some reviewer notes:
* This is using the same strategy as the observability AI assistant via
the discover_shared registry - streams is not an observability-only
plugin, but for now we want to treat it like this. If we move closer to
this becoming a main feature, we can probably have discover depend on
streams directly
* For now, it's only showing the entry in the flyout if streams is
enabled so it's easy to test but doesn't show up accidentally. Before
the initial release, we can change this condition to always show for
observability spaces
* Resolving an index name to a data stream needs an Elasticsearch call
to get the index meta data. I created a new internal route for that. It
means that there is a loading state in theory, but in practice it should
resolve really quickly because it only hits the cluster state, not the
actual data.
* Even if no stream can be resolved it still shows the entry in the
flyout with a `-`. This is because it avoids shifting layout and it
doesn't seem to hurt if it's there.
* As I need to link to streams, I started introducing a locator - I'm
sure it will be needed more soon. I didn't add all the possible routes
yet, we can expand it as needed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to #177932
Inline editing introduced a blurred boundary for the editing experience
in Lens, while the full editor relies on a Redux state manager to
dispatch state changes the inline editor has an hybrid approach.
Specifically the `fixAction` feature in the user messages system needs
access to the redux store which is not available within the embeddable
environment as for now.
So with this PR I've currently limited the scope provided for those
message with a `fixAction` and won't render the button any more.
For instance while investigating #177932 I've noticed that now the
embeddable doesn't crash any more, but rather shows the error message
with the `fixAction` button:
<img width="1496" alt="Screenshot 2025-03-06 at 16 07 35"
src="https://github.com/user-attachments/assets/1b2a5d73-56d9-4010-8a6f-82528efcb2ce"
/>
Note that clicking on the `Use filters` nothing will happen as
d2412a5f98/x-pack/platform/plugins/shared/lens/public/react_embeddable/user_messages/api.ts (L195)
is a mock. A simple `updateAttributes` call here won't suffice as it
requires the logic behind `updateDatasourceState` slice to harmonize the
datasource changes with the visualisation counter part.
With this PR the message will hide the button and render as follow:
<img width="1498" alt="Screenshot 2025-03-06 at 16 18 55"
src="https://github.com/user-attachments/assets/01d55f6c-7563-4e07-a18e-35d1062a8d79"
/>
It is a temporary fix but at least it won't feel broken.
### 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
Closes https://github.com/elastic/streams-program/issues/170 and
https://github.com/elastic/streams-program/issues/171
## Reviewer notes
It's worth reading the research in
https://github.com/elastic/streams-program/issues/168 to understand why
certain decisions were made. Some of the resolving code is inspired by
`grok-js`, unfortunately this wasn't something we could use directly.
The design / UX is **not** final. This is just a functional version. The
editor is currently on the streams > enrichment page so it can be played
with, this will **not** be merged.
There is pattern support for our ECS patterns, I have not added the
legacy ones.
There will almost certainly be some edge cases that don't work, every
repo for a Grok tool I looked at had their own 😅 I've tried to test this
with lots of varied examples though.
I'd recommend unticking "No extension" from the file filter to remove
the pattern files.
<img width="323" alt="Screenshot 2025-03-06 at 22 40 19"
src="https://github.com/user-attachments/assets/5b594f5f-0b0f-4ed0-ae10-2412fcf9e31a"
/>
## Possible improvements / followups
- We could in the future expand the UI to toggle on and off certain
pattern collections.
- Ability to add custom patterns (like in our Grok debugger). This can
still be achieved with `(?<queue_id>[0-9A-F]{10,11})` syntax.
- Point out when regex is invalid (right now it's silent).
- I've copied over the patterns from the ES repo for now, with a light
script to generate an object from them. There's a CLI skeleton in place
if we feel we want to actually pull these from the ES repo directly.
These patterns don't change often, and aren't heavy size wise.
- Debouncing etc for processing, but I'd like to see how the final UX
ends up.
## Media
Screenshot
Simple example
Complex example
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves#212981
## Release Notes
Adds the ability to create an APM availability or latency SLO for all
services
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Kevin Delemme <kdelemme@gmail.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/214709#event-16799922233
The issue was caused by the rollover of the Knowledge Base Data stream
to use default inference endpoint.
During the rollover it first got to this branch
https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/elastic_assistant/server/ai_assistant_service/index.ts#L347-L369
where it went through all the steps and continued, but it didn't
override `this.knowledgeBaseStream`, so the next time someone hit API it
was going through this path calling `getInitializedResources` to make
sure all data streams were configured properly, but because we didn't
update `this.knowledgeBaseStream` it was failing, because the original
configuration that was created in service constructor was not called,
that's why it was returning an error
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
## Summary
Add a new privileges check before executing `applyDataViewIndices`.
This change impacts the API call `applyDataViewIndices` and the job.
`applyDataViewIndices` updates the transforms. Executing without
privileges generates a silence error because the transform can't run.
I also added some extra unit tests for `applyDataViewIndices`.
Required privileges
['read', 'view_index_metadata'] for all security solution dataview +
asset_criticality and risk_score indices.
### How to test it
1. **API call with unprivileged user scenario**
* Enable the entity store with a superuser
* Create an unprivileged user
* Call `POST kbn:api/entity_store/engines/apply_dataview_indices`
* It should return an error
* Add the required privileges
* It executes successfully
2. **Task execution with an unprivileged user scenario**
* Create a user and add privileges only for the required Entity Store
indices
* Login with the new user
* Enable the entity store
* Add a new index to the security data view (the new user shouldn't have
access to the new index)
* Wait for 30min for the job to run, or update the [source
code](8d0feb580f/x-pack/solutions/security/plugins/security_solution/server/lib/entity_analytics/entity_store/tasks/data_view_refresh/data_view_refresh_task.ts (L150))
to make it run more often
* The job execution should fail with an error message containing the new
index name.
### Checklist
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
Adds more coverage for FTRs to test Synonyms UI in serverless.
Adds test cases for synonyms set listing, synoyms set detail and adding
deleting rules.
Covers some happy paths.
### 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.
- [ ] [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_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
