Entity store/schedule maintainers - #2
Closed
chennn1990 wants to merge 176 commits into
Closed
chennn1990 wants to merge 176 commits into
chennn1990 wants to merge 176 commits into
Conversation
…/github.com/chennn1990/kibana into entity-store/entity-maintainers-public-apis
…/github.com/chennn1990/kibana into entity-store/entity-maintainers-public-apis
…/github.com/chennn1990/kibana into entity-store/entity-maintainers-public-apis
…y-store/entity-maintainers-crud-client
…h instructions for new evals (elastic#256314) Closes elastic/streams-program#928 ## Summary Restructures the GCS storage layout for Significant Events snapshot datasets and improves the capture script ergonomics. ### New GCS bucket and folder structure Migrates from the shared `obs-ai-datasets` bucket to a dedicated `significant-events-datasets` bucket with a new path hierarchy that groups datasets under a run ID instead of the other way around: ``` # Before (obs-ai-datasets) dataset-a/run-id-1/snapshot dataset-b/run-id-1/snapshot # After (significant-events-datasets) run-id-1/dataset-a/snapshot run-id-1/dataset-b/snapshot ``` This makes each run ID an "atomic unit" - a single run captures all datasets at a point in time, making it simpler to browse, compare, and clean up old runs. ### OTel Demo snapshot capture script improvements - Auto-starts `minikube` if not already running (with `--cpus=4 --memory=8g`), removing a common manual prerequisite step ### Documentation - Adds a comprehensive README for the significant events evaluation suite covering prerequisites, running evaluations (all/specific datasets/specs), CLI options, environment variables, collected metrics (deterministic, LLM-as-a-judge, trace-based), and guidance for adding new datasets with reproducible capture scripts - Updates the snapshot capture script README to reflect the new bucket name and path structure ### 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) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Documentation** * Added comprehensive documentation for Significant Events evaluations (prereqs, running evaluations, metrics, and how to add datasets/specs). * Updated snapshot capture docs with new GCS base path and naming conventions and revised setup steps. * **New Features** * Added automatic Minikube verification/startup to streamline snapshot capture. * **Tests** * Updated tests to reflect new snapshot path composition. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Relates to: elastic#254973 ## Summary - Add full dataset CRUD management to the evals Kibana plugin, enabling teams to create, view, edit, and delete datasets and their examples directly from the UI instead of managing them only through code. - Server-side: `DatasetClient` backed by storage adapter with two indices (datasets + examples), exposed through 9 new API routes (list, create, get, update, delete datasets; add, update, delete examples; upsert). - UI: new "Datasets" tab alongside the existing "Runs" tab, with a datasets list page and a dataset detail page featuring inline example editing via code editor (JSON), a create/add-example flyout, and delete confirmations. - Wire the offline `@kbn/evals` CLI runner to upsert datasets into the evals plugin when Kibana is available, standardizing dataset ID generation (name-based UUID v5 instead of content hashing) between the plugin and the offline runner. - Add `evaluationsKbnClient` fixture to support a dedicated Kibana endpoint for evals data (via `EVALUATIONS_KBN_URL` / `EVALUATIONS_KBN_API_KEY` env vars), with retry and auth wiring. - Probe evals plugin availability before attempting dataset upserts so the CLI gracefully degrades when the plugin isn't loaded. - Rework the run detail page to group scores by dataset, with per-dataset accordion sections that lazy-load example-level score breakdowns. - New `ExampleScoresTable` component showing per-example scores, evaluator output details, task inputs/outputs in scrollable JSON views, and repetition pagination. - Store task `input` and `output` in score documents so they are available for inspection in the UI. - Remove top-level total scores and traces from the run view in favor of the dataset-grouped layout. - Add suite ID filtering to the runs list page so runs can be narrowed down by suite. ### Datasets list page <img width="1704" height="667" alt="image" src="https://github.com/user-attachments/assets/ae827faf-c7c7-4c11-8bb7-189bef94e8a5" /> ### Dataset detail page (with examples table) <img width="1704" height="706" alt="image" src="https://github.com/user-attachments/assets/e6f6acbe-c62b-4d98-8d66-f5378d53dda3" /> ### Add/edit example via code editor <img width="1704" height="927" alt="image" src="https://github.com/user-attachments/assets/ed2798f9-2fda-4853-bf5e-9e7b8f5a1373" /> ### Run detail page — dataset-grouped scores with example breakdowns <img width="1704" height="927" alt="image" src="https://github.com/user-attachments/assets/a8706ea6-c312-4af6-af70-3619430d2af4" /> ### Testing 0. Make sure you have the evals plugin enabled in `kibana.dev.yml`: ```yaml xpack.evals.enabled: true ``` 1. Start the evals dev server and a dev ES/Kibana instances. Choose Agent Builder eval suite: ```bash yarn es snapshot --license trial yarn start EVALUATION_REPETITIONS=2 TRACING_ES_URL=http://elastic:changeme@localhost:9200 \ EVALUATIONS_ES_URL=http://elastic:changeme@localhost:9200 \ EVALUATIONS_KBN_URL=http://elastic:changeme@localhost:5601/dev \ node scripts/evals start --grep ambiguous ``` 2. Verify the run detail page shows dataset-grouped scores with expandable per-example breakdowns, including task inputs/outputs and evaluator outputs. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Garrett Spong <garrett.spong@elastic.co> Co-authored-by: Viduni Wickramarachchi <viduni.wickramarachchi@elastic.co>
…ime series for input packages (elastic#251205) We are adding support for enabling TSDB in input packages (see elastic/integrations#17183). This is opt-in in the package manifest, but users of input packages can override the data stream type. Prevent time series index mode to be used when the user selects non-metrics data stream types. Also, make TSDB index mode the default for OTel data streams of the metrics type. Change prepared with the support of Copilot+Claude. ## Summary When a package enables the time series index mode, Fleet should prevent using it when the user overrides the data stream type to use a non-metrics type. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] ~~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)~~ - [ ] ~~[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 - [ ] ~~If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)~~ - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks This change is introduced to avoid risks after elastic/package-spec#1066. The only risk could be that we are too cautious and we are preventing enabling TSDB in some corner case of non-metrics data streams. This would not be a regression in any case as it is not possible now to enable TSDB on index packages, as described in elastic/integrations#17183. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This updates the [yaml file](https://github.com/elastic/kibana/blob/main/docs/settings-gen/source/kibana-alert-action-settings.yml) from which we plan to source the [Alerting and action settings](https://www.elastic.co/docs/reference/kibana/configuration-reference/alerting-settings) page. The yaml is updated to: - match the latest settings [schema](https://github.com/elastic/kibana/blob/main/docs/settings-gen/readme.md) (which has reworked `applies_to` tagging, etc.) - update the setting descriptions against the latest Markdown - remove commented-out lines for all of the optional setting parameters - correct setting formatting, data types, and typos - verify in the code whether or not the setting is supported on ECH @florent-leborgne, @theletterf Sorry for the giant diff in this PR. I did check the differences setting by setting and everything looks good to me. I think this would be an ideal yaml file to use for testing the HTML rendering. Rel: elastic#206138
…mode (elastic#253554) ## Summary [See issue](elastic#252527)
## Summary Upgrades immutable to v5.1.5
…nd breakdown dimensions (elastic#254753) ## Summary This PR adds Scout UI (Playwright) e2e coverage for **Metrics in Discover**, focusing on the grid’s key interactions and the Insights flyout experience. It also adds minimal, stable `data-test-subj` hooks in the flyout components to make selectors reliable. ## What’s included - **Insights flyout e2e** - Open flyout from a metric card via **View details** - Verify **Overview** tab content renders - Verify **ES|QL Query** tab renders the query code block - Validate **Dimensions pagination** (jump to last page, next/prev) - **Metrics grid e2e** - Grid activation compatibility across ES|QL commands (`TS`, `WHERE`, `LIMIT`, `SORT`) and non-supported commands (`FROM`, `STATS`) - **Pagination** across metric cards - **Search** filtering and empty state - **Breakdown selector** dimension changes keep grid functional - Metric card actions menu exposes **View details** and **Copy to dashboard**; hover actions expose **Explore** ## Test plan - Run Scout UI tests locally (examples): ```bash # Start a server (choose one) node scripts/scout start-server --arch stateful --domain classic node scripts/scout start-server --arch serverless --domain observability_complete # Run the suite npx playwright test \ src/platform/plugins/shared/discover/test/scout/ui/parallel_tests/metrics_experience/ \ --config src/platform/plugins/shared/discover/test/scout/ui/parallel.playwright.config.ts \ --project local --trace on ``` ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] 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) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] 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) - [ ] 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 - [ ] 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### 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) - [ ] ...
Closes elastic#256140 Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Fixes elastic#256203 This PR changes `slo_instance_id` in the SLO Overview embeddable schema from optional to `required`, with a `defaultValue: ALL_VALUE` ``` slo_instance_id: schema.string({ defaultValue: ALL_VALUE, // "*" meta: { description: 'ID of the SLO instance. Set when the SLO uses group_by; identifies which instance to show. Defaults to * (all instances).', }, }) ``` It also refactors the rendering logic of the SLO embeddable factory. Apart from checking `slo_instance_id` we also need to check if the `slo_id` has `group_by`. This check is needed to correctly render single `SloOverview` card vs `SloCardChartList`. ## How to test ``` # Single SLO POST kbn:/api/dashboards?apiVersion=1 { "title": "Testing SINGLE SLO from Dev Tools", "panels": [ { "config": { "slo_id": "<SLO_ID>", // pick an SLO "overview_mode": "single" }, "grid": { "x": 1, "y": 0, "w": 12, "h": 8 }, "type": "SLO_EMBEDDABLE" } ] } ``` ``` # TEST group_by SLO with a specific instance_id POST kbn:/api/dashboards?apiVersion=1 { "title": "Testing Single group by SLO from Dev Tools with instance id", "panels": [ { "config": { "slo_id": "<SLO_ID>", "slo_instance_id": "<SLO_INSTANCE_ID>", "overview_mode": "single" }, "grid": { "x": 1, "y": 0 }, "type": "SLO_EMBEDDABLE" } ] } ``` ``` # TEST group_by SLO with * specified POST kbn:/api/dashboards?apiVersion=1 { "title": "Testing Single group by SLO from Dev Tools with * instances", "panels": [ { "config": { "slo_id": "92a43b2e-00ec-4a63-a491-9f2cab772d08", "slo_instance_id": "*", "overview_mode": "single" }, "grid": { "x": 0, "y": 0 }, "type": "SLO_EMBEDDABLE" } ] } ``` ``` # TEST group_by SLO without specifying all instances POST kbn:/api/dashboards?apiVersion=1 { "title": "Testing Single group by SLO from Dev Tools without specifying all instances", "panels": [ { "config": { "slo_id": "92a43b2e-00ec-4a63-a491-9f2cab772d08", "overview_mode": "single" }, "grid": { "x": 0, "y": 0 }, "type": "SLO_EMBEDDABLE" } ] } ``` ## Acceptance criteria - `defaultValue: ALL_VALUE` is applied to the `slo_instance_id` - renders `SloCardChartList` when SLO has `group_by` and `slo_instance_id: *` - renders `SloOverview` when single SLO has no group_by (slo_instance_id defaults to *) **Note** Currently on main when we create a dashboard from Devtools specifying an slo_id that has group by but we don't specify any slo_instance_id, then we would end up with a single card view rendered instead of the SloCardChartList. ``` "config": { "slo_id": "92a43b2e-00ec-4a63-a491-9f2cab772d08", "overview_mode": "single" }, ``` <img width="400" height="604" alt="before_defaultValue" src="https://github.com/user-attachments/assets/d09d1f9f-b6ef-4c03-a94f-3ba1883821b4" /> With current rendering logic `SloCardChartList` is properly rendered. <img width="400" height="556" alt="after_defaultValue" src="https://github.com/user-attachments/assets/97699020-5309-4278-847b-e5ec2867799d" />
## Summary Partially completes elastic/kibana-team#2939 This PR: Introduces add to case and add to existing case options in unified rules https://github.com/user-attachments/assets/5a64f06d-f89f-4088-8733-bcb73d6a7563 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…re than 90 days" (elastic#256507) ## Fix: gap auto-fill scheduler fails with "Backfill cannot look back more than 90 days" ### Problem Suppose we have gaps that are 100 days old. Backfill scheduling enforces a 90-day validation limit. The gap auto-fill scheduler fetches all gaps that overlap the `now-90d` range, so these 100-day-old gaps can still be fetched because their interval overlaps that window. Their interval is then clamped to 90 days. Later, when `scheduleBackfill` validates the ranges, it computes its own `now`, which is slightly later because some processing time has elapsed since the task started. As a result, `now - startDate` can become greater than 90 days, and the validation rejects the range with: ```text Backfill cannot look back more than 90 days ``` ### Fix After parsing `gapFillRange`, clamp `startDate` so it stays at least 5 minutes inside the 90-day lookback window. This gives enough buffer for processing delays and ensures the clamped ranges remain safely within the validation limit. ### How to test I created this elastic/security-documents-generator#313 for utility which generate rules with gaps. It allows to have long gaps: 1 rules with 1m interval with 1 gap of 100 days durations `npm run start -- rules --rules 100 -d 100 -i"1m" -c` In main enable gap auto fill scheduler, and observe that execution is failed. In this PR - it should successfully execute the task Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Generated by https://buildkite.com/elastic/kibana-scout-update-metadata/builds/70 Co-authored-by: elasticmachine <scout-updater+elasticmachine@users.noreply.github.com>
…lastic#256086) ## Summary Closes elastic#255318 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - ~[ ] 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)~ - ~[ ] [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 - ~[ ] 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)~ - ~[ ] 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~ - ~[ ] 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)~ - ~[ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels.~ ### 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. - [x] Added a `resolution` field for `@emotion/sheet` to use an [Elastic fork](https://github.com/elastic/emotion) ([see diff](emotion-js/emotion@main...elastic:emotion:main)). We trust any issue this may add can be caught by functional tests, especially the new one added. --------- Co-authored-by: Tomasz Kajtoch <tomasz.kajtoch@elastic.co> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
…lastic#256043) ## Summary Closes elastic/security-team#16228 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] 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) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] 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) - [ ] 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 - [ ] 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### 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) - [ ] ...
…m/chennn1990/kibana into entity-store/schedule-maintainers
chennn1990
pushed a commit
that referenced
this pull request
Mar 29, 2026
…#258775) ## Summary Creates the foundation package `@kbn/evals-extensions` for advanced evaluation capabilities. This package will house features ported from cursor-plugin-evals and serve as the home for Phases 3-5 of the evals roadmap. ## Architecture **One-way dependency:** - ✅ kbn-evals-extensions depends on kbn-evals - ❌ kbn-evals has NO dependency on kbn-evals-extensions Evaluation suites opt-in by importing from extensions directly. ## What's Included ✅ Package structure and build configuration ✅ Comprehensive documentation ✅ 5 passing unit tests ✅ CODEOWNERS entry ✅ No functional changes ## Validation ✅ Bootstrap, type check, tests, eslint, check_changes.ts all passed ✅ No circular dependencies ## Roadmap This enables PRs #2-10 for cost tracking, dataset management, safety evaluators, UI components, DX enhancements, analytics, A/B testing, human-in-the-loop, and IDE integration. ## Related - Part of elastic#257821 - Enables elastic#257823, elastic#257824, elastic#257825, elastic#257826 - Addresses elastic#255820 Co-Authored-By: Claude Sonnet 4.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.5 (1M context) <noreply@anthropic.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Garrett Spong <garrett.spong@elastic.co>
chennn1990
pushed a commit
that referenced
this pull request
Apr 5, 2026
Closes elastic#258318 Closes elastic#258319 ## Summary Adds logic to the alert episodes table to display `.alert_actions` information. This includes: - New action-specific API paths. - Snooze - **Per group hash.** - Button in the actions column opens a popover where an `until` can be picked. - **When snoozed** - A bell shows up in the status column. - Mouse over the bell icon to see until when the snooze is in effect. - Unsnooze - **Per group hash.** - Clicking the button removes the snooze. - Ack/Unack - **Per episode.** - Button in the actions column - When "acked", an icon shows in the status column. - Tags - This PR only handles displaying tags. They need to be created via API. - Resolve/Unresolve - **Per group hash.** - Button inside the ellipsis always - The status is turned to `inactive` **regardless of the "real" status.** <img width="1704" height="672" alt="Screenshot 2026-03-25 at 16 04 12" src="https://github.com/user-attachments/assets/5ef4111a-6e0c-4114-a60e-ce5f81a86ac6" /> ## Testing <details> <summary>POST mock episodes</summary> ``` POST _bulk { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:00:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:01:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "pending" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:02:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:03:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "inactive" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:04:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:05:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:06:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-001", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:07:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:08:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "active" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:09:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "recovering" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:10:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "recovering" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:11:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:12:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "recovering" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:13:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-2", "episode": { "id": "ep-002", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:14:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-003", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:15:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "gh-1", "episode": { "id": "ep-003", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:16:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-4", "episode": { "id": "ep-004", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:17:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-4", "episode": { "id": "ep-004", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:18:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-4", "episode": { "id": "ep-004", "status": "recovering" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:19:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-4", "episode": { "id": "ep-004", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:20:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-5", "episode": { "id": "ep-005", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:21:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-5", "episode": { "id": "ep-005", "status": "pending" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:22:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-5", "episode": { "id": "ep-005", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:23:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-9", "episode": { "id": "ep-006", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:24:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-9", "episode": { "id": "ep-006", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:25:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-9", "episode": { "id": "ep-006", "status": "active" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:26:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-1" }, "group_hash": "elasticgh-9", "episode": { "id": "ep-006", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:14:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-2" }, "group_hash": "elasticgh-7", "episode": { "id": "ep-007", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:15:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-2" }, "group_hash": "elasticgh-7", "episode": { "id": "ep-007", "status": "inactive" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:16:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-3" }, "group_hash": "elasticgh-8", "episode": { "id": "ep-008", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:17:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-3" }, "group_hash": "elasticgh-8", "episode": { "id": "ep-008", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:18:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-3" }, "group_hash": "elasticgh-8", "episode": { "id": "ep-008", "status": "recovering" }, "status": "recovered" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:20:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-4" }, "group_hash": "elasticgh-9", "episode": { "id": "ep-009", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:21:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-4" }, "group_hash": "elasticgh-9", "episode": { "id": "ep-009", "status": "pending" }, "status": "no_data" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:23:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-5" }, "group_hash": "elasticgh-10", "episode": { "id": "ep-010", "status": "pending" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:24:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-5" }, "group_hash": "elasticgh-10", "episode": { "id": "ep-010", "status": "active" }, "status": "breached" } { "create": { "_index": ".rule-events" }} { "@timestamp": "2026-01-27T16:25:00.000Z", "source": "internal", "type": "alert", "rule": { "id": "rule-5" }, "group_hash": "elasticgh-10", "episode": { "id": "ep-010", "status": "active" }, "status": "no_data" } ``` </details> - In the POST above, episodes 1 and 3, and episodes 6 and 9 have the same group hashes. - Go to `https://localhost:5601/app/observability/alerts-v2` and try all buttons. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
chennn1990
pushed a commit
that referenced
this pull request
Apr 15, 2026
…260054) ## Summary issue: elastic/security-team#15982. (Resolves requirement #2) Enriches `SelectionContext` with step `values` so that `PropertySelectionHandler` implementations (`search`, `resolve`, `getDetails`) can access sibling property values from the current step definition. There are no existing steps using `context.values` yet — this is a prerequisite for upcoming steps from the Cases team that need to read sibling properties (e.g. `owner`) to scope their search/resolve logic. ### What changed **`SelectionContext.values`** — A new `values` field (`{ config, input }`) is populated from the step's YAML properties at the time `search`/`resolve`/`getDetails` are called. Handlers can now read sibling values like `context.values.input.owner` instead of having no visibility into the rest of the step. **YAML value extraction fix** — `getValueFromValueNode` now handles non-scalar YAML nodes (arrays/sequences) via `.toJSON()`, fixing a bug where array properties like `owner: [securitySolution]` appeared as `undefined` in `context.values`. **Example** — An example has been implemented in the `examples.externalStep` from the _workflows_examples_ plugin (test with `node scripts/kibana --dev --run-examples`) ### Demo https://github.com/user-attachments/assets/b0cf18ae-5906-4561-bf5e-31b228b08a30 ### Files changed | Area | Files | Change | |------|-------|--------| | Shared types | `kbn-workflows/types/v1.ts`, `latest.ts` | Added `StepSelectionValues` interface, `values` field on `SelectionContext`, generic type parameters on 4 interfaces | | Step registry | `workflows_extensions/.../step_registry/types.ts` | Thread `Config`/`Input` schema types into `StepPropertyHandler` for automatic inference | | Value builder | `build_workflow_lookup.ts` | Added `buildStepSelectionValues()` helper + fixed `getValueFromValueNode` for non-scalar nodes | | Context wiring | `collect_all_custom_property_items.ts`, `get_custom_property_suggestions.ts` | Pass `values` when constructing `SelectionContext` | | Docs | `STEPS.md` | Updated `SelectionContext` type definition and documented `context.values` | | Tests | `build_workflow_lookup.test.ts`, `validate_custom_properties.test.ts`, `get_custom_property_suggestions.test.ts` | New tests for value building (including arrays), updated assertions for new context shape | --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
chennn1990
pushed a commit
that referenced
this pull request
Jun 28, 2026
…c#271863) # Backport This will backport the following commits from `main` to `9.4`: - [[Fleet] Add meta:{id} to fleet schemas (elastic#270560)](elastic#270560) <!--- Backport version: 11.0.2 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Cristina Amico","email":"criamico@users.noreply.github.com"},"sourceCommit":{"committedDate":"2026-05-27T08:37:31Z","message":"[Fleet] Add meta:{id} to fleet schemas (elastic#270560)\n\nFixes https://github.com/elastic/kibana/issues/261258\npossibly also elastic#264565 (to be\nverified)\n\n## Summary\n\nAdd `meta: { id }` to Fleet body/response schemas\n\nFiles changed:\n\n- `server/types/models/agent_policy.ts` — versioned policy schemas\n(v3–v6), `new_agent_policy`, `agent_policy`, `agent_policy_response`,\n`full_agent_policy`, outputs responses\n- `server/types/rest_spec/agent_policy.ts` — bulk get, copy, delete,\nfull policy, K8s manifest, list outputs, cleanup task request/response\nschemas\n- `server/types/models/enrollment_api_key.ts `— `enrollment_api_key`\n- `server/types/rest_spec/enrollment_api_key.ts` — enrollment key CRUD\nand bulk delete schemas\n- `common/types/models/package_policy_schema.ts `— all package policy\nschemas: new, versioned (v22–v24), simplified, update, response,\ndry-run, status\n- `server/types/rest_spec/package_policy.ts` — bulk get, create, delete,\nupgrade, dry-run schemas\n- `server/types/rest_spec/epm.ts `— ~40 package management schemas\n(categories, package info/list/stats, install/delete/bulk operations,\netc.)\n- `server/types/rest_spec/agent.ts` — `action_id_response` /\n`action_message_response` branches of `ActionIdOrMessageSchema`\n(resolves items #1 and #2 of elastic#264565)\n\n### Testing\nVerified locally with:\n```\nnode scripts/capture_oas_snapshot --no-serverless --include-path /api/fleet\nnode scripts/validate_oas_docs\nnode scripts/check_api_contracts --distribution stack\n```\n\nIt looks like there are no Fleet errors left after this change but the\nfinal verification step will be ran in the ci for Terraform\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"f8da12e93c739443107cbaf2e883f1d7a30d9456","branchLabelMapping":{"^v9.5.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport missing","Team:Fleet","backport:version","v9.4.0","v9.5.0"],"title":"[Fleet] Add meta:{id} to fleet schemas","number":270560,"url":"https://github.com/elastic/kibana/pull/270560","mergeCommit":{"message":"[Fleet] Add meta:{id} to fleet schemas (elastic#270560)\n\nFixes https://github.com/elastic/kibana/issues/261258\npossibly also elastic#264565 (to be\nverified)\n\n## Summary\n\nAdd `meta: { id }` to Fleet body/response schemas\n\nFiles changed:\n\n- `server/types/models/agent_policy.ts` — versioned policy schemas\n(v3–v6), `new_agent_policy`, `agent_policy`, `agent_policy_response`,\n`full_agent_policy`, outputs responses\n- `server/types/rest_spec/agent_policy.ts` — bulk get, copy, delete,\nfull policy, K8s manifest, list outputs, cleanup task request/response\nschemas\n- `server/types/models/enrollment_api_key.ts `— `enrollment_api_key`\n- `server/types/rest_spec/enrollment_api_key.ts` — enrollment key CRUD\nand bulk delete schemas\n- `common/types/models/package_policy_schema.ts `— all package policy\nschemas: new, versioned (v22–v24), simplified, update, response,\ndry-run, status\n- `server/types/rest_spec/package_policy.ts` — bulk get, create, delete,\nupgrade, dry-run schemas\n- `server/types/rest_spec/epm.ts `— ~40 package management schemas\n(categories, package info/list/stats, install/delete/bulk operations,\netc.)\n- `server/types/rest_spec/agent.ts` — `action_id_response` /\n`action_message_response` branches of `ActionIdOrMessageSchema`\n(resolves items #1 and #2 of elastic#264565)\n\n### Testing\nVerified locally with:\n```\nnode scripts/capture_oas_snapshot --no-serverless --include-path /api/fleet\nnode scripts/validate_oas_docs\nnode scripts/check_api_contracts --distribution stack\n```\n\nIt looks like there are no Fleet errors left after this change but the\nfinal verification step will be ran in the ci for Terraform\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"f8da12e93c739443107cbaf2e883f1d7a30d9456"}},"sourceBranch":"main","suggestedTargetBranches":["9.4"],"targetPullRequestStates":[{"branch":"9.4","label":"v9.4.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.5.0","branchLabelMappingKey":"^v9.5.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/270560","number":270560,"mergeCommit":{"message":"[Fleet] Add meta:{id} to fleet schemas (elastic#270560)\n\nFixes https://github.com/elastic/kibana/issues/261258\npossibly also elastic#264565 (to be\nverified)\n\n## Summary\n\nAdd `meta: { id }` to Fleet body/response schemas\n\nFiles changed:\n\n- `server/types/models/agent_policy.ts` — versioned policy schemas\n(v3–v6), `new_agent_policy`, `agent_policy`, `agent_policy_response`,\n`full_agent_policy`, outputs responses\n- `server/types/rest_spec/agent_policy.ts` — bulk get, copy, delete,\nfull policy, K8s manifest, list outputs, cleanup task request/response\nschemas\n- `server/types/models/enrollment_api_key.ts `— `enrollment_api_key`\n- `server/types/rest_spec/enrollment_api_key.ts` — enrollment key CRUD\nand bulk delete schemas\n- `common/types/models/package_policy_schema.ts `— all package policy\nschemas: new, versioned (v22–v24), simplified, update, response,\ndry-run, status\n- `server/types/rest_spec/package_policy.ts` — bulk get, create, delete,\nupgrade, dry-run schemas\n- `server/types/rest_spec/epm.ts `— ~40 package management schemas\n(categories, package info/list/stats, install/delete/bulk operations,\netc.)\n- `server/types/rest_spec/agent.ts` — `action_id_response` /\n`action_message_response` branches of `ActionIdOrMessageSchema`\n(resolves items #1 and #2 of elastic#264565)\n\n### Testing\nVerified locally with:\n```\nnode scripts/capture_oas_snapshot --no-serverless --include-path /api/fleet\nnode scripts/validate_oas_docs\nnode scripts/check_api_contracts --distribution stack\n```\n\nIt looks like there are no Fleet errors left after this change but the\nfinal verification step will be ran in the ci for Terraform\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"f8da12e93c739443107cbaf2e883f1d7a30d9456"}}]}] BACKPORT--> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
chennn1990
pushed a commit
that referenced
this pull request
Jun 30, 2026
…mp (elastic#273513) ## Summary Addresses elastic#273086 (follow-ups #2 and #3 to elastic#273418). Several Synthetics queries that target a specific `monitor.check_group` carried **no `@timestamp` bound**, so Elasticsearch could not prune shards during the `can_match` pre-filter and fanned the query out across **all** `synthetics-*` backing indices — including the deliberately-throttled **frozen** tier (searchable snapshots). On clusters with long frozen retention (e.g. `hot: 3d / warm: 4d / frozen: 365d`) this caused slow screenshot/history loading and contributed to cluster-wide **search thread pool rejections**. All documents of a single Synthetics check run (summary, steps, screenshots, network events) are written at essentially the same instant, so any query scoped to one `check_group` can safely be bounded to a **wide window around that run's `@timestamp`** without risking dropping a run's documents — while still letting `can_match` skip unrelated (frozen) shards. > This is complementary to elastic#273418: that PR added opt-in tier exclusion (`observability:searchExcludedDataTiers`) at the `SyntheticsEsClient` choke point; this PR makes the per-run queries naturally prunable even when an operator has not opted in. ### What changed - New shared helper `getCheckGroupTimeRangeFilter(timestamp)` in `common/constants/client_defaults.ts` — builds a `@timestamp` range of `[ts - 1h, ts + 1h]` (the buffer is far larger than any realistic journey duration, so it can never drop a run's docs). - **Screenshots** (`get_journey_screenshot`): accepts an optional `timestamp` and bounds the query. Threaded end-to-end from the UI: `getScreenshotUrl` → `JOURNEY_SCREENSHOT` route → handler. The run timestamp already reaches `JourneyStepScreenshotContainer` / `JourneyLastScreenshot`, so the overview "last screenshot" (the customer's main symptom) is now bounded. - **Steps** (`get_journey_steps`): accepts an optional `timestamp` and bounds the query. Threaded via `useJourneySteps` → `fetchBrowserJourney` → `JOURNEY` route. Wired from `JourneyLastScreenshot`, `LastTestRun`, and the expanded successful-result row. - **Last successful check** (`last_successful_check` route): bounds its follow-up screenshot lookup to the resolved check's own `@timestamp` (fully self-contained — the route already has the timestamp). - **#3 — Recent pings** (`fetchMonitorRecentPings`): reduced the unused fallback window from **30 days → 24h** for when callers don't pass an explicit range (the only caller, `TestRunsTable`, always passes the UI date range, so this is hygiene on the fallback path). ### Behavior / risk - All new `timestamp` parameters are **optional**; when absent, queries behave exactly as before, so this is backward-compatible for any caller that doesn't pass one. - Bounding is provably non-lossy: a check group's documents share the run instant, and the `± 1h` window dwarfs any journey duration. ### Remaining follow-ups (still tracked in elastic#273086, not in this PR) - Network events (`get_network_events`) and screenshot blocks (`get_journey_screenshot_blocks`) — same optional-`timestamp` pattern; deferred to keep this PR focused. - Latest-ping hooks (`useRemoteMonitorLatestPing`, `use_status_by_location`, `use_monitor_detail`) — these need a `24h→7d→30d` fallback (a hard bound could hide infrequently-run monitors), better done alongside `get_latest_test_run`. ## Testing - `node scripts/jest` for the changed areas — added unit tests: - `get_journey_screenshot.test.ts` / `get_journey_steps.test.ts`: query is bounded when `timestamp` is provided and unchanged when absent. - `journey_screenshot_dialog.test.tsx`: `getScreenshotUrl` appends a url-encoded `timestamp` (and both `remoteName` + `timestamp`). - `browser_journey/api.test.ts`: `fetchBrowserJourney` forwards `timestamp`. - `node scripts/type_check --project x-pack/solutions/observability/plugins/synthetics/tsconfig.json` — passes. - `node scripts/eslint --fix $(git diff --name-only)` — clean. ### Checklist - [x] Unit tests updated/added for the changed query paths. - [ ] [Release Notes](https://www.elastic.co/guide/en/kibana/master/release-notes.html) — performance improvement. --------- Co-authored-by: Cursor <cursoragent@cursor.com>
chennn1990
pushed a commit
that referenced
this pull request
Jul 5, 2026
…orm (elastic#276036) Fixes elastic#265639 ### Summary - The service map embeddable spec timed out on the `Last 24 hours` preset because it passed the all-underscore label `Last_24_hours` to `datePicker.setCommonlyUsedTime`. - That form only resolves on the new `DateRangePicker` (`dateRangePickerPresetItem-Last_24_hours`); on the legacy `EuiSuperDatePicker` fallback the emitted test-subj is `superDatePickerCommonlyUsed_Last_24 hours` (only the first space becomes `_`), so the click never landed when the picker-detection lost the race to the legacy path on a slow cloud-serverless worker. - Aligns the three APM calls to the repo-wide convention (`Last_24 hours`), which resolves on both picker variants — matching every other `setCommonlyUsedTime` caller and this file's own `clickCommonlyUsedTimeRange('Last_24 hours')` usage. This is the actionable half of the [Failed Test Investigator's June 13 analysis](elastic#265639 (comment)) (fix #1, the legacy-fallback selector mismatch). Its fix #2 — the `isNewDateRangePicker` 5 s race — is already implemented on `main`: the shared `date_picker.ts` now waits for either picker via `newPicker.or(legacyPicker).waitFor()`. Rather than reshape the shared page object used by dozens of callers, this fixes the lone outlier caller, keeping the blast radius to one test file. <details> <summary>Verification</summary> #### Verified locally - Confirmed via repo-wide grep that every other `setCommonlyUsedTime` caller uses the first-space-only form (e.g. `Last_24 hours`, `Last_15 minutes`, `This_week`), matching EUI's emitted `superDatePickerCommonlyUsed_Last_24 hours` test-subj; the APM spec was the sole `Last_24_hours` outlier. - Confirmed the same spec already uses the correct `Last_24 hours` form in its `clickCommonlyUsedTimeRange` calls, so the two paths are now consistent. #### Not verified locally - Could not run `yarn kbn bootstrap`, ESLint, or the Scout spec in this sandbox (dependencies not installed — `@kbn/setup-node-env` missing), so the test was not executed against a live Kibana/Elasticsearch. - Behavior under CI parallel load on `cloud-serverless-observability_complete` (the only lane where this flaked) is not reproduced here. </details> > [!NOTE] > Created by the Flaky Test Fixer workflow, requested by @jennypavlova. Share feedback or questions in #apps-qa. > Generated by [Flaky Test Fixer](https://github.com/elastic/kibana/actions/runs/28605583212) for issue elastic#265639 · 175 AIC · ⌖ 12.2 AIC · ⊞ 3.5K · [◷](https://github.com/search?q=repo%3Aelastic%2Fkibana+%22gh-aw-workflow-id%3A+flaky-test-fixer%22&type=pullrequests) <!-- gh-aw-agentic-workflow: Flaky Test Fixer, engine: claude, version: 2.1.165, model: opus, id: 28605583212, workflow_id: flaky-test-fixer, run: https://github.com/elastic/kibana/actions/runs/28605583212 --> <!-- gh-aw-workflow-id: flaky-test-fixer --> <!-- gh-aw-workflow-call-id: elastic/kibana/flaky-test-fixer --> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1. CRUD API in entity maintainers
run/setupreceive acrudClientin their context so they can use the entity CRUD API.CRUDClientper run and passes it into the maintainer methods.2. Stop/start via Task Manager (no reschedule, state kept)
taskManager.bulkUpdateState()(settaskStatustoSTOPPEDorSTARTED). Tasks are not unscheduled or rescheduled.taskStatuseach run: ifSTOPPED, it skips execution. Fixes: no repeatedsetupafter stop/start, and stopped maintainers are not rescheduled; task state is preserved.3. Init decoupled from install + dedicated init endpoint
assetManager.init(...).POST …/entity_maintainers/initendpoint: validates privileges and that entity store is installed (400 if not), then callsentityMaintainersClient.init()to schedule only maintainers that don’t yet have a task document.4. First Security visit: install + init
useInstallEntityStoreV2(Security app): if entity store is installed → init entity maintainers only; if not installed and default space → install then init; otherwise no-op.5. Scout tests
entity_maintainers_init.spec.ts: privilege checks (403), init behavior (schedule never-started, idempotent second init, no restart of stopped, 200 when all have tasks), and 400 when entity store not installed.6. Uninstall tears down maintainers
entityMaintainersClient.removeAll()after uninstalling entity types, so entity maintainer tasks are removed as part of entity store uninstall.Note: Registry no longer stores
taskStatus; status comes from the task state (NEVER_STARTEDwhen no task document exists).