## Summary
This PR removes unused pipeline tests from the packaging of integration.
The pipeline tests are not run today when the integration is built.
Hence removing them for now.
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 1 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/logs-overview` | `x-pack/platform/packages/shared/logs-overview`
|
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/.i18nrc.json
./x-pack/platform/packages/shared/logs-overview/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/platform/packages/shared/logs-overview/jest.config.js:10
x-pack/platform/packages/shared/logs-overview/tsconfig.json:2
```
</details>
Closes#211257
## Summary
Regression introduced in 8.18
(https://github.com/elastic/kibana/pull/199286)
We no longer pass the `system` message to the inference plugin, and
thereby the LLM. This means that we are only passing user messages to
the LLM. The system message is important in steering the conversation,
and providing guardrails to the LLM.
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 1 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/search-shared-ui` | `x-pack/solutions/search/packages/shared-ui`
|
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-relocate/utils/transforms.ts
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/.i18nrc.json
./x-pack/solutions/search/packages/shared-ui/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/search/packages/shared-ui/jest.config.js:14
x-pack/solutions/search/packages/shared-ui/tsconfig.json:2
```
</details>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 2 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/observability-ai-common` |
`x-pack/solutions/observability/packages/observability-ai/observability-ai-common`
|
| `@kbn/observability-ai-server` |
`x-pack/solutions/observability/packages/observability-ai/observability-ai-server`
|
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/solutions/observability/packages/observability-ai/observability-ai-common/jest.config.js
./x-pack/solutions/observability/packages/observability-ai/observability-ai-server/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/observability/packages/observability-ai/observability-ai-common/jest.config.js:10
x-pack/solutions/observability/packages/observability-ai/observability-ai-common/tsconfig.json:2
x-pack/solutions/observability/packages/observability-ai/observability-ai-server/jest.config.js:10
x-pack/solutions/observability/packages/observability-ai/observability-ai-server/tsconfig.json:2
```
</details>
## Summary
[Internal link](https://github.com/elastic/security-team/issues/10820)
to the feature details
Part of https://github.com/elastic/security-team/issues/11232
This PR covers SIEM Migrations Stats APIs:
* Retrieves the stats for the specific migration: (route: `GET
/internal/siem_migrations/rules/{migration_id}/stat`)
* Retrieves the stats for all the existing migrations, aggregated by
`migration_id`: (route: `GET /internal/siem_migrations/rules/stats`)
* Retrieves the translation stats for the migration: (route: `GET
/internal/siem_migrations/rules/{migration_id}/translation_stats`)
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/observability-utils-browser` |
`x-pack/solutions/observability/packages/utils-browser` |
| `@kbn/observability-utils-common` |
`x-pack/solutions/observability/packages/utils-common` |
| `@kbn/observability-utils-server` |
`x-pack/solutions/observability/packages/utils-server` |
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/solutions/observability/packages/utils-browser/jest.config.js
./x-pack/solutions/observability/packages/utils-common/jest.config.js
./x-pack/solutions/observability/packages/utils-server/jest.config.js
./x-pack/solutions/observability/packages/utils-server/jest.integration.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/observability/packages/utils-browser/jest.config.js:10
x-pack/solutions/observability/packages/utils-browser/tsconfig.json:2
x-pack/solutions/observability/packages/utils-common/jest.config.js:10
x-pack/solutions/observability/packages/utils-common/tsconfig.json:2
x-pack/solutions/observability/packages/utils-server/jest.config.js:10
x-pack/solutions/observability/packages/utils-server/jest.integration.config.js:10
x-pack/solutions/observability/packages/utils-server/tsconfig.json:2
```
</details>
Closes#203740
## Summary
I managed to reproduce the failure locally only once and it happened
because the wrong tab was clicked. It is hard to reproduce it so I was
thinking about a way to avoid the step of clicking on the tab: As this
test is checking only the permissions I changed the navigation to open
the tab from the beginning of the test (with the main flow we test the
same navigation so we don't have to repeat the same steps here to test
the tab content)
## Summary
[Internal link](https://github.com/elastic/security-team/issues/10820)
to the feature details
Part of https://github.com/elastic/security-team/issues/11232
This PR covers SIEM Migrations Update API (route: `PUT
/internal/siem_migrations/rules/{migration_id}`) integration test:
* Happy path
* update migration
* ignore attributes that are not eligible for update
* Error handling
* an empty content response
* an error when rule's id is not specified
* an error when undefined payload has been passed
Also, as part of this PR, I added error handling cases for Create API:
* no content error
* an error when undefined payload has been passed
* an error when original rule id is not specified
* error when original rule vendor is not specified
* an error when original rule title is not specified
* an error when original rule description is not specified
* an error when original rule query is not specified
* an error when original rule query_language is not specified
---------
Co-authored-by: Sergi Massaneda <sergi.massaneda@gmail.com>
In a bunch of places we would directly show `error.message` in toasts.
This is not always the right value, because the actual error is
sometimes wrapped in an HttpError. At some places we would already
unpack this correctly using a helper function - I made sure it's used
everywhere.
One example where this can be tested is when trying to map a child in an
incompatible way - let's say a field is mapped as long in
`logs.child.subchild`, then the user tries to map the same field as
keyword in `logs.child`. Previously it would just say "BadRequest", now
it says:
<img width="378" alt="Screenshot 2025-02-14 at 15 02 53"
src="https://github.com/user-attachments/assets/0abb51db-2bac-407e-bb51-beb74b3f9adb"
/>
**Addresses:** https://github.com/elastic/kibana/issues/202078
## Summary
This PR extends rule upgrade test plan with customizable and
non-customizable field examples. Rule upgrade workflow test plan
(excluding Rule Upgrade flyout) was initially extended in
https://github.com/elastic/kibana/pull/203331.
https://github.com/elastic/kibana/pull/203331 adds the following rule
upgrade workflow scenarios
- Scenario: User can upgrade conflict-free prebuilt rules one by one
- Scenario: User cannot upgrade prebuilt rules one by one from Rules
Update table if they have conflicts
- Scenario: User can upgrade multiple conflict-free prebuilt rules
selected on the page
- Scenario: User cannot upgrade selected prebuilt rules with conflicts
- Scenario: User can upgrade all available conflict-free prebuilt rules
at once*
- Scenario: User cannot upgrade all prebuilt rules at once if they have
upgrade conflicts
- Scenario: User can upgrade only conflict-free rules when a mix of
rules with and without conflicts are selected for upgrade
- Scenario: User can upgrade only conflict-free rules when attempting to
upgrade all rules
- Scenario: User can upgrade rule with rule type change individually
- Scenario: User can not bulk upgrade selected rules with rule type
changes
- Scenario: User can not bulk upgrade all rules with rule type changes
- Scenario: API does not upgrade prebuilt rules if they are up to date
---------
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
## Summary
This PR fixes Rule Management Prebuilt Rules preview Cypress tests flakiness. The flakiness was localized to `prebuilt_rules_preview.cy.ts`.
## Problem details
Quite recently Rule Management Prebuilt Cypress tests group started failing due to exceeding 1 hour execution limit. In normal conditions the group takes up to 45 minutes to run all the tests.
Investigation revealed the problem. It turned out the real prebuilt rules get installed while it's not expected. The absolute majority of the tests interact with a few prebuilt rule assets mocks to avoid heavy prebuilt rules package installation and installing more than 1K rules from the package.
In particular `/internal/detection_engine/prebuilt_rules/_bootstrap` endpoint is invoked upon loading any Security Solution plugin's page and leads to installing a prebuilt rules package. The Cypress test code was organized in way that first the Rule Management page is opened and then API calls interception is set up. Since page loading may vary sometimes real calls to `/internal/detection_engine/prebuilt_rules/_bootstrap` went through.
Tests set up prebuilt rule assets mocks but real prebuilt rules package installation wiped out the mocks leading to failing tests. Since Cypress reruns failed tests execution time increases and exceeds the limit.

*`installPrebuiltRuleAssets()` sets up `/internal/detection_engine/prebuilt_rules/_bootstrap` calls interception.
## Flaky test runs
**Before:**
- `prebuilt_rules_preview.cy.ts` was run in Flaky test runner with 100 iterations. The CI is green but it's easy to notice some jobs took approximately 1 hour to run.
🔴https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7870
**After:**
- `prebuilt_rules_preview.cy.ts` with the fix was run in Flaky test runner with 100 iterations. Execution time approximately 15 minutes for each job.
✅https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7873
- Rule Management Prebuilt Cypress tests group was run with 100 iterations
✅https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7875
## Summary
Closes https://github.com/elastic/streams-program/issues/88
Adds JSON advanced field mapping parameters to the Schema Editor.
Main questions here are around the types and data structure. In this PR
these are added as an `additionalProperties` property, but we may also
want to have all of these parameters top level (like `type` and
`format`). This version makes separating concerns easier in the UI and
separating "first class" options vs advanced options, I could see pros
and cons to both, and also things might be "upgraded" from advanced to
first class later on. Also an open question on whether the
`MappingProperty` type needs to be explicitly redefined for Zod (ES will
obviously reject anything that isn't supported here).


Connected with https://github.com/elastic/kibana/issues/195188
## Summary
- Moved the params of tracking containment rule type to
`@kbn/response-ops-rule-params/geo_containment` package
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Connected with https://github.com/elastic/kibana/issues/195188
## Summary
- Moved the params of transform health rule type to
@kbn/response-ops-rule-params/transform_health package
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/208016
Adds a new dataset for the tag-association test (didn't find a good
existing one)
For the MKI flakiness, I don't think this is related to this test but
rather another test leaking SOs. I added some robustness against this,
but ideally we fix this in the offending test. Maybe we should add a
little something that checks for leaky state after a suite closes and
fails if there is something? That goes beyond the scope of this issue
though.
## Summary
At the moment, when you click on the notify badge in the "rules" page,
then click it again (expecting a toggle) it actually gets stuck on the
page and only a refresh can fix it.
This change adds a toggle and implements it in place of the
"openPopover" to correctly toggle the state of the popover.
### 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)
## Release Notes
Fixes an issue where the popover in the rules page may get stuck when
being clicked more than once.
Before:
https://github.com/user-attachments/assets/2f092d63-ab69-41df-9047-1ba11481ea15
After:
https://github.com/user-attachments/assets/d1ef9abc-e0ee-44cb-ae75-0219047c4a67
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/21030
It was a quick work to do while we don't have many tests yet.
For reviewers: we most likely will review and update the rules to align
better with final test design for Scout before GA. I don't think we have
to deep dive into what rules are missing, but just to make sure I didn't
restrict something important from your perspective.
Rules are described in
https://github.com/playwright-community/eslint-plugin-playwright?tab=readme-ov-file#rules
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes a bug due to multiple subscription created by the ESQL
variables logic in the embeddable to never been cancelled.
The fix was to move the subscription in the loader module and make it
cleanup correctly together with other subscription.
Unit tests have been added to check the correct re-render behaviour.
### 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
Resolves https://github.com/elastic/eui-private/issues/169
## Summary
This PR makes Borealis the default theme in Serverless (traditional
kibana flavor already uses Borealis as the default) and adds a
`coreRendering.defaultThemeName` LD feature flag to allow a graceful
switch when this code gets deployed next week.
To switch back to Amsterdam when developing locally, set
`feature_flags.overrides.coreRendering.defaultThemeName: amsterdam` in
`kibana.dev.yml`
Please note that `DEFAULT_THEME_TAGS` still includes both Amsterdam and
Borealis. We've decided to keep Amsterdam bundled in case of any
unexpected errors. We'll make Amsterdam opt-in and reduce the bundle
size within the next two weeks (target date Feb 21st).
For the sake of a straightforward review of this PR, I will remove the
previously defined `theme:name` UI setting and `themeSwitcherEnabled`
logic in a follow-up PR.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
### Summary
- Closes#89741
This PR contains the resulting work of a massive effort that ports our
on top bundler abstraction (called @kbn/optimizer) from Webpack v4 into
Webpack v5. It's essential in terms of long term maintenance since v4
was not receiving updates any longer but will also unblock some new
features that could be beneficial for our future DevEx endeavours.
Next you can find a small list of all the accomplished tasks on this
journey.
### Completed Tasks
- [x] Upgrade dependencies to match the ones on webpack v5
- [x] Fix null-loader usages
- [x] Fix raw-loader usages
- [x] Fix file-loader usages
- [x] Fix url-loader usages
- [x] Fix `@kbn/optimizer-webpack-helpers` to support webpack v5
- [x] Adopt previous webpack v4 polyfill-all strategy with
node-polyfill-webpack-plugin
- [x] Fix theme-loader on @kbn/optimizer
- [x] Migrate configurations and ad-hoc loader options on all webpack
configs from v4 to v5
- [x] Fix @kbn/test jest resolver for file-loader cases
- [x] Migrate public-path loader on UiSharedDeps
- [x] Fix all usages of webpack-merge
- [x] Migrate BundleRemoteModule
- [x] Migrate BundleRemotesPlugin
- [x] Correctly migrate PopulateBundleCachePlugin
- [x] Correctly migrate BundleMetricsPlugin
- [x] Check if the profiling plugins still work (--profile flag)
- [x] Recover if possible the previous webpack v4 cacheGroup chunks
rename to something like `data.plugin.chunk.0.js`
- [x] Run `/ci` and make sure we get our first green CI, otherwise work
on the errors until we do
- [x] Profile and solve bottlenecks until we get a cold build
performance similar to the one we had on webpack v4 (`node
scripts/build_kibana_platform_plugins --no-cache`).
- [x] OpenSSL Legacy Warnings: try to remove `--openssl-legacy-provider
` flags
- [x] Add Webpack to Renovate config
- [x] Explore removing `NodePolyfillPlugin`
([here](https://www.npmjs.com/package/node-polyfill-webpack-plugin)) and
add each polyfill needed individually per each webpack config to check
if we get smaller bundles. If we do it's better to go with the case by
case need approach instead of deploying a bunch of polyfills with
NodePolyfillPlugin. As another alternative, create a custom smaller
plugin with only the union of all needed polyfills.
- [x] Evaluate if we want to touch the resolutions on mainFields and
conditionNames
- [x] Understand why `@import 'src/core/public/mixins'` does not work
anymore (not a problem, we should use relative paths anyway but we want
to track why it changed from v4 to v5)
- [x] BUG: Child compilers are having errors hidden and/or changed from
error to warning
- [x] Fix license check for
[Artistic-2.0](https://spdx.org/licenses/Artistic-2.0.html) is the
license for
[domain-browser](https://github.com/bevry/domain-browser?tab=License-1-ov-file).
This package is a dependency of
[NodePolyfillPlugin](https://www.npmjs.com/package/node-polyfill-webpack-plugin).
Artistic 2.0 license is [classified as
yellow](https://github.com/elastic/open-source/blob/main/elastic-product-policy.md#yellow-list)
and should only be used for dev dependencies.
- [x] Make sure `resourceQuery: { not: /raw/ }` is not necessary on
other webpack configs like storybook one
- [x] Find what is being wrongly removed by usedExports optimization;
hint: I believe it is identifying a lot of exports inside the sync entry
of plugins as unused exports and removing them. Then `__kbnBootstrap__`
can't be found
- [x] Rebalance @kbn/optimizer pickMaxWorkerCount
- [x] Re-open the issue to fix sass-warnings
[#190345](https://github.com/elastic/kibana/issues/190345) or downgrade
sass-loader to v10
- [x] Remove previous esm no parse rules
- [x] Confirm esm support is working
- [x] Confirm console override is needed
- [x] Confirm react prod builds on ui shared deps for distributable
- [x] Remove customization for
[xyflow](https://github.com/xyflow/xyflow) from webpack configs
- [x] Clean all the code
- [x] Make sure collected metrics from stats are still aligned with what
we were collecting before; also verify if the modules used for optimizer
caches etc are well generated (@kbn/node-libs-browser)
- [x] Fix watch performance
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Brad White <brad.white@elastic.co>
## Summary
Related to https://github.com/elastic/kibana/issues/206710
While working on https://github.com/elastic/kibana/pull/210831, I
discovered some issue with the way we convert tool response messages
from langchain (json as string) to the inference plugin's internal
format (parsed/structured json).
In practice, this impacts mostly the `gemini` adapter, as it's the only
one expecting strictly an object type for the tool response (and the
provider throws an error otherwise). Other providers such as bedrock and
openAI already receive responses as strings, so we were mostly
double-encoding the content, which is fine for the LLM's understanding
of the call.
This PR addresses it, by properly parsing tool call responses in the
langchain->inference conversion logic, and add a second layer of safety
with an additional check in the Gemini adapter directly.
This PR also add a new `signal` parameter to the `InferenceChatModel`
constructor, as I also discovered that some of the security's usages of
langchain are passing the signal that way instead of passing it for each
individual model invocations (which makes sense for chains and graphs).