## 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>
This PR **might** resolve
https://github.com/elastic/kibana/issues/207011 but we will need time
for the telemetry metrics to settle before we know for sure.
## Summary
This PR removes the conditional rendering of the default drag handle in
`kbn-grid-layout`, which has two benefits:
1. It removes the double render of `GridPanel` that was caused by
relying on the `dragHandleCount` to be updated in order to determine
whether the default drag handle should be rendered
2. The default drag handle no longer "flashes" when Dashboards are
loading and waiting for `dragHandleCount` to update
- **Before:**
https://github.com/user-attachments/assets/30a032fc-4df3-42ce-9494-dd7f69637c03
- **After:**
https://github.com/user-attachments/assets/db447911-cbe2-40dd-9a07-405d1e35a75d
Instead, the consumer of `kbn-grid-layout` is responsible for setting
the `useCustomDragHandle` prop to `true` when they want to use a drag
handle other than the default one.
When adding the `useCustomDragHandle` prop, I got annoyed that I had to
pass this prop all the way down to `grid_panel` - so I decided to swap
to using React context in this PR, as well. The API for the grid layout
component will most likely continue to grow, so this should make it
easier to manage the props.
### 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
- [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
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).
Currently, streams logs with a `stream` field fail ingest because the
set processor tries to set a
```
"stream": {
"name": "<name field>"
}
```
which doesn't work if `"stream": "abc"` is already in the document (some
shippers do this, e.g. docker or kubernetes)
Using a painless processor this problem can be avoided and you can have
`"stream"` and `"stream.name"`
## Summary
Both files were incorrectly assigned in
https://github.com/elastic/kibana/pull/207969. This PR corrects the
assignment to the security solution team.
- /x-pack/test_serverless/functional/test_suites/security/constants.ts
- /x-pack/test_serverless/api_integration/test_suites/security
Also, the ownership assinment of
`/x-pack/test_serverless/**/test_suites/security/platform_security` was
moved below
`/x-pack/test_serverless/api_integration/test_suites/security`, to
maintain hierarchical ownership.
Fixes https://github.com/elastic/kibana/issues/206921
### Problem
The visualize embeddable is inconstant when passing runtime state to
`buildEmbeddable`. Sometimes, only `{ savedObjectId }` is provided. The
embeddable tried to work around this by calling `deserializeState` in
`buildEmbeddable`.
There was a different bug with the `deserializeState` guard in
`buildEmbeddable` where state like `{ savedObjectId, savedVis: {} }`
would not pass the guard. Dashboard adds runtime state so `savedVis` was
getting added to `initialState` and thus failing the guard
This resulted in the visualize embeddable trying to initialize with
state `{ savedObjectId }` instead of state in the shape `{
savedObjectId, serializedVis: {} }`. This resulted in error message like
"Could not read properties of undefined" when the embeddable tried to
read from `state.serializedVis.type`.
### Solution
The solution is to ensure that `buildEmbeddable` is always passed
runtime state containing `serializedVis`. This pattern is in line with
the lens embeddable.
### Test instructions
* install sample web logs
* create agg based visualization
* create new dashboard, add agg based visualization. Open context menu
of vis and select "Unlink from library". (Side note, removing legacy
visualizations from add panel makes it hard to add by-value agg based
visualizations to a dashboard)
* save dashboard
* edit agg based vis
* Click "Save to library" and fill out form
* Verify visualization is rendered in dashboard.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR addresses an issue where users with read privilege to insights
were unable to successfully complete a remediation path due to the
inability to mark an insight as remediated at the final step.
With this change, we adjust the required permissions for interacting
with the update API from writeWorkflowInsights to readWorkflowInsights.
The rationale behind this is that writeWorkflowInsights should signify
the ability to trigger new scans for insights, while
readWorkflowInsights should be sufficient for addressing found issues
without the option to generate new ones.
https://github.com/user-attachments/assets/8c1af654-d9e4-40d7-8718-1388677e8d46
Addresses #206436
- Replace styled-components with @emotion/react and @emotion/styled
across multiple components
- Remove `@kbn/ui-theme` instances
- Update test cases to use @emotion/jest matchers for toHaveStyleRule to
work properly
- Adjust styles to use `css` from `@emotion/react`
- Remove unused imports and updated snapshots
https://github.com/user-attachments/assets/48b9ab41-23fd-4c00-ace9-c0cbe58c91f7
## Summary
- Adds a new kibana feature privilege to the `Security > Endpoint`
grouping for "Manage Global Artifacts"
- new privilege is behind the following feature flag:
`endpointManagementSpaceAwarenessEnabled`
- new privilege is not yet being used in this PR. Subsequent PRs that
will introduce space awareness changes for endpoint management will
leverage this new privilege
- Fixes the `All` and `Read` labels to ensure they can be localized
(`i18n`)
## Summary
Fixes a small UI bug in the citations feature. Previously, after a
message with citations finished streaming, the citations would disappear
for a fraction of a second and then reappear again. This PR makes
improves the UI by making the citations not flash off and on after the
stream finishes.
### Changes:
- Fix flashing citations
- Refactor code related to parsing content references (to make it more
maintainable).
- Update the citations prompt slightly.
### Before:
https://github.com/user-attachments/assets/1021dd53-018a-43ba-b1f4-24aab44faca9
<img width="1782" alt="image"
src="https://github.com/user-attachments/assets/723cd29a-48a2-48e7-b031-0893484746b9"
/>
### After:
https://github.com/user-attachments/assets/21f340bc-9015-42b6-a574-0439d2f8f192
### How to test
- Enable the feature flag
```yaml
# kibana.dev.yml
xpack.securitySolution.enableExperimental: ['contentReferencesEnabled']
```
- Open the security assistant
- Ask it a question about your alerts of a document in your KB. The
response should contain citations.
- Observe the response stream carefully. Ensure the citations e.g. `[1]`
do not flash off and on when the response stream finishes. The expected
behavior is that while the message is streaming, the citations are
disabled and once the stream finishes the citations get enabled (while
always being visible).
#### Edge case to test
It is possible that citations completely disappear after streaming
finishes. This happens when the LLM produces an invalid citation.
Invalid citations are hidden client side when a message finishes
streaming. You can verify this behavior by asking GPT4o this question:
```
Prepend each line with this placeholder citation "{reference(1234)}" and append the actual citation at the end of the line. How many alerts do I have? Use the open and acknowledged alerts count tool to answer and repeat the answer 50 times on new lines.
```
While the response is getting streamed it should look like this:
<img width="200" alt="image"
src="https://github.com/user-attachments/assets/03d160bf-2404-4a4e-8701-e3183c604cc4"
/>
And when the stream finishes it should look like this:
<img width="200" alt="image"
src="https://github.com/user-attachments/assets/06367379-17da-438f-a93a-9d539067ab90"
/>
### 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/src/platform/packages/shared/kbn-i18n/README.md)
- [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
- [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.
- [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)
### 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>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/195418
Gives `ROW` and `SHOW` autocomplete logic its own home 🏡
### 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
### Identify risks
- [ ] As with any refactor, there's a possibility this will introduce a
regression in the behavior of FROM. However, all automated tests are
passing and I have tested the behavior manually and can detect no
regression.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Refactor screenshot block route to not return 404 !!
Route will return empty list instead of 404 for missing screenshot
blocks !!
This also updates to enable _inspect on route !!
### Testing
Screenshot still works as expected
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/9a2b887d-9091-4bff-97e6-3c0775e6f6bd"
/>
Unwired streams can come with or without a default ingest pipeline
defined. If there is a pipeline defined, it's clear where to plug in our
custom parsing logic.
However, so far we would bail out on streams without a configured ingest
pipeline. However, since there are good reasons to have data streams
without an ingest pipeline, we should support this case.
This PR makes sure we do:
* If the streams processing pipeline is the default pipeline itself
already, everything is fine
* If there is none yet, extend the user-managed index template to set
the default pipeline to the streams processing pipeline and roll over
the data stream to apply
## Summary
This PR deletes the "Critical Services" component from the Entity
Analytics Dashboard header.
The component was included with the service entity store, but Product
and QA consider it confusing and not very valuable to our users.
### How to test it?
* Start Kibana with security data
* Go to the security solution/entity analytics dashboard
* The component shouldn't be there
`99.1.0-borealis.0` ⏩ `99.2.0-borealis.0`
[Questions? Please see our Kibana upgrade
FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)
---
## [`v99.2.0`](https://github.com/elastic/eui/releases/v99.2.0)
- Changed `EuiFieldText` styles to prioritize `disabled` styling over
`readonly`. ([#8271](https://github.com/elastic/eui/pull/8271))
- Added `plugs` and `web` glyphs to `EuiIcon`
([#8285](https://github.com/elastic/eui/pull/8285))
- Update `title` on `EuiColorPalettePickerPaletteProps` to be optional
([#8289](https://github.com/elastic/eui/pull/8289))
**Bug fixes**
- Fixed an issue with EuiDataGrid with auto row height resulting in a
table of 0 height ([#8251](https://github.com/elastic/eui/pull/8251))
- Fixed `disabled` behavior of `EuiFieldText` to prevent input changes.
([#8271](https://github.com/elastic/eui/pull/8271))
**Borealis changes**
- [Visual Refresh] Provide hooks for color palette functions
([#8284](https://github.com/elastic/eui/pull/8284))
- [Visual Refresh] Make Borealis default theme in EUI
([#8288](https://github.com/elastic/eui/pull/8288))
---
As you can probably tell, there are plenty of updated tests and
snapshots this time around. They are the result of the following:
1. We've updated the default theme in `@elastic/eui` v99.2.0 to
Borealis, which led to kibana tests using `renderWithTheme`,
`mountWithTheme`, and other utility functions that wrap the tested
component in `<EuiThemeProvider>` to switch to the correct, new color
values. With this change, all tests should now use Borealis, regardless
of the testing framework or its configuration.
2. Because of the default theme change in EUI, some class name hash
fragments (e.g., `css-`**`wprskz`**`-euiButtonIcon-xs-empty-primary`)
regenerated.
Most Borealis-related changes in this PR are test env only and have no
impact on what users see when using Kibana.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `8df3ca6` ->
`d74b1fd` |
---
### 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://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/195418
Gives `FROM` and `METADATA` autocomplete logic its own home 🏡
### 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
### Identify risks
- [ ] As with any refactor, there's a possibility this will introduce a
regression in the behavior of FROM. However, all automated tests are
passing and I have tested the behavior manually and can detect no
regression.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Addresses: https://github.com/elastic/observability-dev/issues/4222
The intent of this PR is to improve the kind of telemetry/metrics that
are captured when there is a fatal error in rendering a React component
in Kibana.
### 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
### 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.
- [ ] Risk of re-visiting this work if we need to add more
instrumentation (APM spans, etc)
## Summary
- Implements #178138
- Fixes a bug where clicking on the existing link to the monitor via the
name badge led failed to load any data.
## Release Notes
- Fixes a bug where clicking on the name badge for a synthetics monitor
on an SLO details page would lead to a page that failed to load monitor
details.
- Adds a working link to the location badge on synthetics SLOs that will
route the user to the monitors page with a filter applied that matches
the location of the origin SLO.
## Summary
This PR will drastically reduce the number of console logs from the
Detection Engine in the overview cluster. If your team is depending on
the `INFO`, `WARNING`, or `verification_exception` or `ml job missing`
`ERROR` logs in that cluster, please raise your concerns here.
Addresses https://github.com/elastic/kibana-team/issues/1395,
https://github.com/elastic/kibana-team/issues/1333
Historically Detection Rules have written an enormous amount of data to
the console logs. This was helpful in debugging years ago before we had
the event log, but now we generally don't use them much. The console
logs all still get scooped up and sent to the overview cluster though.
Every rule execution writes two or more status changes (first to
'running', then to the final status later on) and these go to the
console, the event log, and the rule SO. The end result is 76% of all
logs are coming from detection rules changing status, mostly successful
statuses. These provide little value on their own.
This PR restricts console logging from detection rules to only non-user
errors. User errors and execution statuses below the error level will be
logged in the console at the `debug` level. "Unexpected" errors like
search exceptions, timeouts, etc will still appear as errors in the
console logs. The general idea is that the logs from detection rules in
the console should represent some kind of unexpected system failure.
To implement this change, I updated the console logging logic in both
the security rule execution logger. User errors reported to the
framework will still create console error logs since they're logged at
the framework level.
## Testing
Create rules that run and generate warnings (e.g. missing index), user
errors (EQL verification exceptions), and non-user errors. An easy way
to create a non-user error at the moment is running a threshold rule
when at least one index searched maps `@timestamp` as a `keyword`
instead of `date`. The non user errors still show up in console logs as
errors. User errors and warnings only show up as debug logs and with
debug logging enabled in the Kibana config.
