Related: https://github.com/elastic/kibana/pull/216397
This fixes a bug in the Lock Manager where an expired lock can be
acquired, but the token and metadata is not updated. This means that the
lock cannot be released. Instead it is automatically released when the
TTL expires.
## Summary
- Fixes https://github.com/elastic/kibana/issues/203607🤞
- Refactored classic navigation FTRs to wait on page to load between
changing pages
- Updated classic nav expected items for current apps
- Updated solution navigation tests to match classic & serverless test
case objects
- Updated solution nav `expectOnlyDefinedLinks` to be strict on index of
expected items. This tests _should_ fail when we move a side nav item,
but it wasn't as written.
### 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] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
When navigating to the endpoint exceptions form from an alert, we
pre-populate certain exceptions fields based on the type of alert. There
was a bug for behavior alerts where we did not use the proper nested
`code_signature` field for windows and mac endpoints. Instead of showing
the nested `code_signature` field that has the `subject_name` and
`trusted` sub-fields, we only showed non-nested `code_signature subject
field. This PR also refactors the code to account for the following
behaviors that we want:
- [x] If `field.Ext.code_signature` is present, we want to use the
nested `code_signature` subject field with the `subject_name` and
`trusted` sub-fields for
- [x] If `field.Ext.code_signature` is not present, we will default to
the non-nested `field.code_signature.subject_name` and
`field.code_signature.trusted` field pair.
- [x] We will only show non-empty pre-populated values and also only
code signature values with the `trusted` field set to `true`
- [x] Pre-populated code signature fields are only present in windows
and mac OSes.
- [x] Behavior, ransomware and default alerts had the code_signature
adjustments
- [x] Previously the code duplicated a set of the pre-populated fields
PER code signature. Now, each pre-populated field is only shown once,
followed by all valid code_signatures.
- [x] Does not allow duplicate code signatures
# SCREENSHOTS
Behavior alert w/ nested `process.Ext.code_signature` and non-nested
`dll.code_signature` fields
Malware alert w/ nested `file.Ext.code_signature`
<img width="1281" alt="image"
src="https://github.com/user-attachments/assets/4845c6e5-5567-49df-b66a-1b9a2e6410db"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Resolves#211945.
Uptime is not available on Serverless projects, so we are seeking to
remove the tutorial and the integration search result.
To achieve this, I added an optional `omitServerless` field to the
tutorial spec and implemented it on the Uptime tutorial spec. I added
additional filtering to the registration procedures, and referenced the
`buildFlavor` in the plugin's setup code.
_NOTE:_ This resolves#211945, but if this solution is not acceptable to
the maintainers please advise me on a better approach.
Example:
<img width="898" alt="image"
src="https://github.com/user-attachments/assets/5ebd52a0-b8e8-4198-9a92-d67fa4ad0ff4"
/>
<img width="696" alt="image"
src="https://github.com/user-attachments/assets/b2b1ec65-6353-4415-a55f-33ac9f7977fe"
/>
## Summary
This is a follow up PR to expose the metric
`frozen_indices_queried_max_count` on the rule healthcheck endpoint.
This metric is an aggregation of the metric
`frozen_indices_queried_count` which is calculated upon rule execution.
Refer to [this PR](https://github.com/elastic/kibana/pull/218435) to see
more details about it.
## How to test this?
- Run Elastic locally with these additional parameters in order to
enable the frozen data tier: -E path.repo="/tmp" -E
xpack.searchable.snapshot.shared_cache.size=20GB.
- Use [this
tutorial](https://docs.elastic.dev/security-soution/analyst-experience-team/eng-prod/how-to/configure-local-frozen-tier)
to create the snapshot repository and an ILM policy. You can disable
rollover for the ILM policy and configure indices to be moved to frozen
after 0 days.
- Create an index manually and populate it with a couple of documents.
- Assign the ILM policy to the index you created in the previous step
and wait for it to be rolled to frozen. You can run this command to
speed up the process:
```
PUT /_cluster/settings
{
"persistent": {
"indices.lifecycle.poll_interval": "10s"
}
}
```
You can confirm that the index is indeed in frozen by calling
```
GET <YOUR_IDX_HERE>/_ilm/explain
```
`phase` should be `frozen` and `step` should be `complete`.
- Create a rule querying the frozen index.
- Call the rule health endpoint with:
```
curl -X POST --user elastic:changeme "http://localhost:5601/internal/detection_engine/health/_rule?date_start=2025-04-29T09:07:39.489Z&date_end=2025-05-01T09:08:39.489Z" \
-H "Content-Type: application/json" \
-H "elastic-api-version: 1" \
-H 'kbn-xsrf: 123' \
-H "x-elastic-internal-origin: Kibana" \
--data '{"rule_id":"2f9780b5-7819-4685-ab8e-d817d3701d10"}'
```
You should see `frozen_indices_queried_max_count` populated with `1`.
## Summary
The following changes were done in support of Endpoint space awareness:
- The background task that checks and completes pending 3rd party
response actions was updated to ensure that action are completed using a
response actions client scoped to the space that the response action was
created from.
- The automated response actions process was updated to use the alert's
space ID when retrieving a response action client
Updating release notes for 9.0.1 (docs V3) in main branch.
Not sure how we plan to deal with the security advisor messages in the
release notes in the new docs system, considering the release notes page
include a generic message at the beginning pointing to the security
advisory board.
Also I'm not totally sure if this needs to be merged into any other
branch, I'll let @wajihaparvez and @florent-leborgne to determine how
this should be done, and approve or reject the PR.
## Summary
Updates the internal reporting health API from
https://github.com/elastic/kibana/pull/216857 to return whether the
notification email service is available. We'll be using this
notification email service to send the scheduled report notifications so
this lets us know if that service is available.
```
GET kbn:/internal/reporting/_health
Response
{
"has_permanent_encryption_key": true,
"is_sufficiently_secure": true,
"are_notifications_enabled": true
}
```
## To Verify
1. Run kibana and ES with a preconfigured email connector in the
`kibana.yml` and the notification configured to use the connector
```
notifications.connectors.default.email: gmail
xpack.actions.preconfigured:
gmail:
name: 'email: my gmail'
actionTypeId: '.email'
config:
<config>
secrets:
<secrets>
```
2. Access the health API, `are_notifications_enabled` should be `true`
3. Remove the config and restart Kibana
4. Access the health API, `are_notifications_enabled` should be `false`
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Sets up a repository action that runs the issue re-labelling action from
https://github.com/elastic/kibana-github-actions/pull/56
It's set up to run on a hourly schedule for a few target projects.
Todo:
- [x] add all relevant project numbers
- [x] replace personal key with a kibana-operations key
## Summary
Follow directions here for creating a rollup index -
https://github.com/elastic/kibana/pull/187235
Ensure the documentation links render on the right in each of the rollup
creation steps.
Closes https://github.com/elastic/kibana/issues/218076.
Part of the preparation for migrating Kibana to React’s createRoot
([Epic](https://github.com/elastic/kibana-team/issues/1564)).
## What’s in this PR
- Switch to `createRoot` in tests: Updates `@testing-library/react` to
use `createRoot` by default. All unit tests using Testing Library now
run in concurrent mode. See commit:
8e51e07054
- Test updates: Most test failures from the switch have been addressed.
About a dozen tests still explicitly set `legacyRoot: true`. These will
need closer review by the owning teams during app migrations.
- Enzyme tests: Enzyme tests continue to use the React 17 adapter and
run in legacy mode. [Current
plan](https://docs.google.com/document/d/1CXybQiBAtXt3Kay0j_CJxWO7bZ2EYYhaveK4fban2-M/edit?tab=t.kfgvma8ti7q0)
is to migrate away from Enzyme before upgrading to React 19.
## Background
When we upgraded to React 18, we also updated `@testing-library/react`,
which by default uses `createRoot`.
To avoid dealing with concurrent mode failures early, we temporarily
forced Testing Library to use `legacyRoot` (`ReactDOM.render`).
This PR removes that override and fixes the resulting test issues,
completing the move to concurrent root for Testing Library tests.
### Common Failures
#### 🔴 `el.click()`
A common testing mistake is using el.click() and immediately checking
for a DOM update:
```
el.click();
expect(el).toHaveAttribute('state-updated');
```
This often fails with Concurrent React, because state updates might not
be synchronous anymore.
Directly calling `el.click()` doesn't automatically trigger React’s
update cycle (`act`), so your test can read outdated DOM.
Instead, you should either manually wrap the interaction in `act`, or
(better) use `userEvent.click`, which already uses `act` internally and
simulates real user behavior more accurately:
```diff
- el.click();
+ await userEvent.click(el);
expect(el).toHaveAttribute('state-updated');
```
#### 🔴 Wrapping `render` call inside `act` `act(() => render(<App/>))`
Another common mistake is wrapping the render call inside act:
```
await act(async () => {
render(<MyComponent />);
});
```
This is sometimes done to "mute" warnings about Promises resolving
inside `useEffect`.
However, wrapping `render` in `act` manually breaks a lot of tests in
Concurrent React, because the library (like React Testing Library)
already wraps render in act internally. Manually adding act here can
cause unexpected behavior, like missing updates or wrong timing.
The approach I took was to remove the manual `act` around `render` in
places where tests started failing with Concurrent React, even if, in
some cases, it means seeing `act` warnings in the console. This is safer
for correctness and allows the tests to pass reliably.
To properly mute such warnings, the right way would be to wrap the
actual resolved Promises (like those inside useEffect) in act.However,
since doing that depends a lot on the specific test setup, and could
vary case-by-case, I chose not to try to fix it myself. Teams are
welcome to follow up if they wish.
### 🟡 In specific tests we keep `legacyMode: true`
When it wasn't immediately clear to me what caused the failure or when
the tests were checking React internals, like the number of re-renders,
I decided to keep that test running in legacy mode by using the option
`legacyRoot: true` in `render`.
The idea behind these in-place overrides is that when we're ready to
start migrating the runtime to concurrent mode, the owning teams will
need to take a closer look at those tests when moving their apps to the
concurrent root.
## Summary
This bugfix solves an issue with trace documents loaded in Discover with
the relative timeframe of "now" to last n minutes, where the traces that
are the closest to "now" do not load their waterfal widget on the
document profile overview tab. The use of `useTimeFilter` yields an
incorrect absolute timestamp that does not correspond to the time range
of the data loaded, with a slight discrepancy for the `end` parameter,
where the trace's timestamp could be later than what is provided for the
`end` timestamp. This then causes the traces waterfall endpoint to
return no data, due to an incorrect timestamp.
Switching to `getAbsoluteTime()` appears to resolve this by returning a
more accurate absolute timestamp, which corresponds more directly to the
data loaded, not when the page was accessed/loaded. As a result, the
endpoint request becomes well-formed and returns the trace waterfall
data correctly.
Closes#220383
## How to test
* Add this to your kibana.dev.yml file:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Enable the Observability mode for the current space, then navigate to
Discover
* Create/use a data-view or use an ES|QL query that targets a traces-*
index.
* Ensure the time filter is set to `Last 15 minutes` and select the
first/latest trace document and open the document view for it.
* Check that the trace loads the Trace Waterfall widget correctly.
* Repeat with older traces, and with a changed time filter where the
`end` is not `now`.
* All opened traces should show a trace waterfall on the overview tab.
Closes https://github.com/elastic/kibana/issues/220248
- This PR removes the write index blocks that were previously added when
starting a reindex operation. The index blocks were added to prevent
writes to the source index, while it was being re-indexed to a target
index.
- Re-enables tests to run on MKI
Why index blocks should be removed:
- Immediately after creating the target index, the KB write index alias
is pointed over to the new target index. This means that it is possible
to ingest documents to the new target index, while the re-index is in
progress. Thus, we no longer need to block writes
- Index blocks must be cleaned up. If a node crashes after a re-index
operation has been started, the reindex operation itself will continue
to run because it is handled by Elasticsearch with all the guarantees it
provides. However, the index block will not be removed again, causing a
permanent dead lock until customers remove the index block themselves.
Customers should not end up in this situation.
- Index blocks are causing tests to fail, when the index block is not
properly cleaned up afterwards:
https://github.com/elastic/kibana/issues/220248
---------
Co-authored-by: Viduni Wickramarachchi <viduni.wickramarachchi@elastic.co>
Co-authored-by: Viduni Wickramarachchi <viduni.ushanka@gmail.com>
## Summary
When importing a content pack into a stream, we now store an object to
audit this import.
In addition to the content pack metadata that can now be surfaced, we
also store metadata of the saved objects imported to remember the source
object it was copied from. This allows updates of existing objects
instead of creating a duplicate.
The stored metadata is restricted to the stream/content pack name on
purpose as it's not clear yet how versioning will be handled for content
pack and dashboards.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`useBatchedOptionalPublishingSubjects` should only be used when `api` is
not available until after rendering. This PR replaces usages of
`useBatchedOptionalPublishingSubjects` with
`useBatchedPublishingSubjects` where possible.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR addresses the issue where if user tried to renavigate to
Findings page (with filter on) from Vulnerability Contextual Flyout by
clicking on the popup icon in the Vulnerability Details table the filter
on Findings page won't get formed properly IF some of the fields value
contains special character such as "+", this happen when user gets
redirected to Findings page
in the case of "+", this malformed filter is caused because in the URL
"+" gets encoded into "%20" which is space instead of "%2b" which is "+"
https://github.com/user-attachments/assets/ce4007a1-b0ad-4ce4-b389-53c44a43aa9b
Part of https://github.com/elastic/kibana/issues/216491
Adds telemetry for linked dashboards and investigation guide fields that
are coming soon: https://github.com/elastic/kibana/issues/214522,
https://github.com/elastic/kibana/issues/213024
- Number of rules with linked dashboards
- Number of rules with non-empty investigation guide
To test, you can use the following API call. The result should include
two new fields: `count_rules_with_linked_dashboards` and
`count_rules_with_investigation_guide`
```
POST kbn:/internal/telemetry/clusters/_stats?apiVersion=2
{
"unencrypted": true,
"refreshCache": true
}
```
### Note
I have added a comment to update one test file
(`x-pack/test/alerting_api_integration/common/lib/get_test_rule_data.ts`)
once `artifacts` field is available in schema.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from `x-pack/test` to
`x-pack/platform/test`
Before:
```
x-pack/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
After:
```
x-pack/platform/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
Additional:
- `x-pack/test/api_integration/apis/osquery/config.ts` was move to
platform stateful manifest to match `osquery` plugin (shared, platform)
- `automatic_import_api_integration` config files were moved to platform
stateful manifest to match `automatic_import` plugin (shared, platform)
- `x-pack/test/common/lib/test_data_loader.ts` is required by SO api
tests and was copied to `x-pack/platform/test/common`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#220289 and
https://github.com/elastic/opentelemetry-lib/issues/168
## Summary
This PR fixes an issue with the processes query in case the document is
missing some of the required fields for the aggregation (like user.name,
process.pid, system.process.cpu.total.pct, etc.). This PR adds a filter
to the query to ensure that all the required fields exist
| Before | After |
| ------ | ------ |
|
|
|
## Testing
> [!NOTE]
> With the oblt lite cluster, the issue is reproducible as in the
screenshot (one of the hosts using the hostsmetrics receiver),
I also tested with metricbeat for regressions and the host Otel
Onboarding steps locally (the processes are not available there, just
the summary)
- Go to the asset details page and open the processes tab
- There shouldn't be an error shown when loading the processes
