Synthetics review feedback by nreese · Pull Request #1 · yiannisnikolopoulos/kibana

nreese · 2026-02-19T15:54:38Z

I figured it would be easier to leave my review feedback as a PR

@elasticmachine

…on (elastic#258531) The `integrations_automatic_import.cy.ts` test was consistently failing at the deploy step with `Bad Request (400): Building the Integration failed` because the test invoked the real `buildPackage()` server endpoint and the real Fleet package install endpoint — neither of which were mocked, unlike the generation graph endpoints (ECS, categorization, related). ## Changes - **`integrations_automatic_import.cy.ts`**: Add `cy.intercept` mocks in `beforeEach` for the two un-mocked endpoints: - `POST /internal/automatic_import/build` → returns `200 {}` - `POST /api/fleet/epm/packages` → returns `200` with `_meta.name: 'test_integration-1.0.0'`, which is what `getIntegrationNameFromResponse()` reads to set `integrationName` and render the success section ```typescript cy.intercept('POST', '/internal/automatic_import/build', { statusCode: 200, body: {}, }); cy.intercept('POST', '/api/fleet/epm/packages', { statusCode: 200, body: { _meta: { install_source: 'upload', name: 'test_integration-1.0.0' }, items: [], }, }); ```  <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Failing test: Fleet Cypress Tests #1 / Add Integration - Automatic Import should create an integration</issue_title> > <issue_description>https://buildkite.com/elastic/kibana-pull-request/builds/412255#019d019d-c8e8-429d-aa99-0585b8e3fc05 > should create an integration > Add Integration - Automatic Import should create an integration > > > Owners: > Unable to determine code owners > Failures in tracked branches: 1 > https://dryrun/ > Buildkite Job > https://buildkite.com/elastic/kibana-pull-request/builds/412255#019d019d-c8e8-429d-aa99-0585b8e3fc05 > > AssertionError: Timed out retrying after 60000ms: Expected to find element: `[data-test-subj="integrationSuccessSection"]`, but never found it. > at Context.eval (webpack://@kbn/fleet-plugin-cypress/./e2e/integrations_automatic_import.cy.ts:107:45) > > <img width="1440" height="900" alt="Image" src="https://github.com/user-attachments/assets/c7e54d6f-85e3-4e2b-87e8-1602c716788d" /> > > Logs: [kibana-pull-request_build_412706_fleet-cypress-tests.log](https://github.com/user-attachments/files/26113748/kibana-pull-request_build_412706_fleet-cypress-tests.log)</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > <comment_new><author>@elasticmachine</author><body> > Pinging @elastic/fleet (Team:Fleet)</body></comment_new> > </comments> > </details>  - Fixes elastic#258522  --- 📱 Kick off Copilot coding agent tasks wherever you are with [GitHub Mobile](https://gh.io/cca-mobile-docs), available on iOS and Android. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: juliaElastic <90178898+juliaElastic@users.noreply.github.com>

@timestamp

Closes elastic#258317 ## Summary The alert episodes table needs to display episode status for each row. To build that UI, we needed a bulk-get API for alert actions. ### Testing <details> <summary>Start by posting some mock action data.</summary> ``` POST .alerting-actions/_bulk {"create":{}} {"@timestamp":"2026-03-18T08:00:00.000Z","last_series_event_timestamp":"2026-03-18T07:55:00.000Z","actor":"user-1","action_type":"ack","group_hash":"gh-1","episode_id":"ep-001","rule_id":"rule-1"} {"create":{}} {"@timestamp":"2026-03-18T08:10:00.000Z","last_series_event_timestamp":"2026-03-18T07:55:00.000Z","actor":"user-1","action_type":"snooze","group_hash":"gh-1","episode_id":"ep-001","rule_id":"rule-1"} {"create":{}} {"@timestamp":"2026-03-18T08:30:00.000Z","last_series_event_timestamp":"2026-03-18T07:55:00.000Z","actor":"user-2","action_type":"deactivate","group_hash":"elasticgh-2","episode_id":"ep-002","rule_id":"rule-1","reason":"Known maintenance window"} {"create":{}} {"@timestamp":"2026-03-18T08:45:00.000Z","last_series_event_timestamp":"2026-03-18T07:55:00.000Z","actor":"user-2","action_type":"ack","group_hash":"elasticgh-2","episode_id":"ep-002","rule_id":"rule-1"} {"create":{}} {"@timestamp":"2026-03-18T09:00:00.000Z","last_series_event_timestamp":"2026-03-18T08:50:00.000Z","actor":"user-1","action_type":"ack","group_hash":"elasticgh-3","episode_id":"ep-003","rule_id":"rule-2"} {"create":{}} {"@timestamp":"2026-03-18T09:15:00.000Z","last_series_event_timestamp":"2026-03-18T08:50:00.000Z","actor":"user-1","action_type":"unack","group_hash":"elasticgh-3","episode_id":"ep-003","rule_id":"rule-2"} {"create":{}} {"@timestamp":"2026-03-18T09:30:00.000Z","last_series_event_timestamp":"2026-03-18T09:20:00.000Z","actor":"user-3","action_type":"snooze","group_hash":"elasticgh-4","episode_id":"ep-004","rule_id":"rule-2"} {"create":{}} {"@timestamp":"2026-03-18T09:50:00.000Z","last_series_event_timestamp":"2026-03-18T09:20:00.000Z","actor":"user-3","action_type":"unsnooze","group_hash":"elasticgh-4","episode_id":"ep-004","rule_id":"rule-2"} {"create":{}} {"@timestamp":"2026-03-18T10:00:00.000Z","last_series_event_timestamp":"2026-03-18T09:50:00.000Z","actor":"user-2","action_type":"deactivate","group_hash":"elasticgh-5","episode_id":"ep-005","rule_id":"rule-3","reason":"Duplicate alert"} {"create":{}} {"@timestamp":"2026-03-18T10:20:00.000Z","last_series_event_timestamp":"2026-03-18T09:50:00.000Z","actor":"user-1","action_type":"activate","group_hash":"elasticgh-5","episode_id":"ep-005","rule_id":"rule-3","reason":"Re-enabled after investigation"} {"create":{}} {"@timestamp":"2026-03-18T10:30:00.000Z","last_series_event_timestamp":"2026-03-18T10:25:00.000Z","actor":"user-1","action_type":"ack","group_hash":"elasticgh-6","episode_id":"ep-006","rule_id":"rule-3"} {"create":{}} {"@timestamp":"2026-03-18T10:45:00.000Z","last_series_event_timestamp":"2026-03-18T10:25:00.000Z","actor":"user-1","action_type":"snooze","group_hash":"elasticgh-6","episode_id":"ep-006","rule_id":"rule-3"} {"create":{}} {"@timestamp":"2026-03-18T10:55:00.000Z","last_series_event_timestamp":"2026-03-18T10:25:00.000Z","actor":"user-2","action_type":"deactivate","group_hash":"elasticgh-6","episode_id":"ep-006","rule_id":"rule-3","reason":"Root cause fixed"} {"create":{}} {"@timestamp":"2026-03-18T11:00:00.000Z","last_series_event_timestamp":"2026-03-18T10:55:00.000Z","actor":"user-3","action_type":"ack","group_hash":"elasticgh-7","episode_id":"ep-007","rule_id":"rule-4"} {"create":{}} {"@timestamp":"2026-03-18T11:30:00.000Z","last_series_event_timestamp":"2026-03-18T11:20:00.000Z","actor":"user-2","action_type":"snooze","group_hash":"elasticgh-8","episode_id":"ep-008","rule_id":"rule-4"} {"create":{}} {"@timestamp":"2026-03-18T11:45:00.000Z","last_series_event_timestamp":"2026-03-18T11:20:00.000Z","actor":"user-2","action_type":"ack","group_hash":"elasticgh-8","episode_id":"ep-008","rule_id":"rule-4"} {"create":{}} {"@timestamp":"2026-03-18T12:00:00.000Z","last_series_event_timestamp":"2026-03-18T11:50:00.000Z","actor":"user-1","action_type":"deactivate","group_hash":"elasticgh-9","episode_id":"ep-009","rule_id":"rule-5","reason":"Alert storm - suppressing"} {"create":{}} {"@timestamp":"2026-03-18T12:10:00.000Z","last_series_event_timestamp":"2026-03-18T11:50:00.000Z","actor":"user-1","action_type":"snooze","group_hash":"elasticgh-9","episode_id":"ep-009","rule_id":"rule-5"} {"create":{}} {"@timestamp":"2026-03-18T12:30:00.000Z","last_series_event_timestamp":"2026-03-18T12:20:00.000Z","actor":"user-3","action_type":"ack","group_hash":"elasticgh-10","episode_id":"ep-010","rule_id":"rule-5"} {"create":{}} {"@timestamp":"2026-03-18T12:40:00.000Z","last_series_event_timestamp":"2026-03-18T12:20:00.000Z","actor":"user-3","action_type":"unack","group_hash":"elasticgh-10","episode_id":"ep-010","rule_id":"rule-5"} {"create":{}} {"@timestamp":"2026-03-18T12:50:00.000Z","last_series_event_timestamp":"2026-03-18T12:20:00.000Z","actor":"user-3","action_type":"ack","group_hash":"elasticgh-10","episode_id":"ep-010","rule_id":"rule-5"} ``` </details> There are up to 10 episodes with actions, all with ids like `ep-001`. Query the new route and confirm that the results are as expected. ``` POST kbn:/internal/alerting/v2/alerts/action/_bulk_get { "episode_ids": ["ep-001", "ep-002", "ep-003", "foobar"] } ``` --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

@timestamp

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": "elasticgh-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": "elasticgh-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": "elasticgh-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": "elasticgh-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": "elasticgh-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": "elasticgh-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": "elasticgh-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>

…#263470) ## Summary Several small, independent optimizations to the Kibana PR CI pipeline. Timing data below is measured from actual Buildkite logs (baselines #427940–#427945 vs PR builds #428076, #428363, #428619). ### 1. Parallel bootstrap + artifact download (`common.sh`) All functional/integration test steps (FTR, Scout, Cypress) previously ran bootstrap and distributable download sequentially. They are independent: - **Bootstrap** installs `node_modules` so `node scripts/functional_tests` can run. - **Artifact download** fetches and extracts the ~426 MiB Kibana distributable tarball. This is the biggest win in the PR. Running them in parallel lets the download (the typical bottleneck) overlap with bootstrap. **Measured (yarn start → first `node scripts/functional_tests`, FTR Configs #1):** | Build | Bootstrap | Download | Total setup | | --- | --- | --- | --- | | #427940 (baseline) | 42s | 20s | 63s | | #427941 (baseline) | 57s | 32s | 93s | | #427942 (baseline) | 41s | 15s | 57s | | #427943 (baseline) | 35s | 20s | 56s | | #427944 (baseline) | 41s | 36s | 81s | | #427945 (baseline) | 42s | 36s | 83s | | **Baseline avg** | | | **~72s** | | #428076 (PR) | parallel | 37s | **38s** | | #428363 (PR) | parallel | 38s | **39s** | | #428619 (PR) | parallel | 36s | **39s** | **Per-step savings: ~20–55s (avg ~33s)**, depending on how slow the baseline download happened to be. With ~230 FTR/Scout/Cypress steps per PR build, that's on the order of **~1.5–2 hours of aggregate agent-time**. Error handling preserves the previous behavior: bootstrap and download PIDs are waited on individually and each exit code is propagated. ### 2. Background docker image cleanup (`build_kibana.sh`) `clean_cached_images` (prunes Docker images to free disk space) took ~20s synchronously before the Kibana build. `node scripts/build` takes ~7.5 minutes and doesn't use Docker, so the cleanup is backgrounded and completes well before the archive step that actually benefits from the freed space. **Measured in the Build Kibana Distribution step: ~21s saved.** | Build | Docker cleanup wait | | --- | --- | | Baseline avg (6 builds) | **21.1s** | | #428076 / #428363 / #428619 (PR) | **0.0s** | ### 3. Simplified archive extraction (`build_kibana.sh`) Previously the archive step extracted the tarball to an intermediate `install/kibana` directory and then did a recursive copy to `$KIBANA_BUILD_LOCATION`. Now it extracts directly to the build location in a single `tar` command, eliminating the redundant `cp -pR` and temporary directory. **Measured savings: ~3s** in the finalize→archive phase. ### 4. Custom checkout plugin for Build Kibana Distribution step (`base.yml`) Replaces the default checkout with the `custom-checkout#v1.8.0` plugin configured for a shallow fetch (`--depth=1`, `--no-tags`, `--single-branch`), using the local git mirror at `/opt/git-mirrors/git-github-com-elastic-kibana-git`. The Kibana CI agents already run with a warm git mirror, so the default checkout is not downloading full history — the actual data transferred on a default checkout is a few MiB, not GB. The benefit of this change is modest but consistent: skipping tag refs and reducing pack-transfer round-trips. **Measured (Receiving objects in Build Kibana Distribution log):** | Variant | Objects | Data transferred | | --- | --- | --- | | Baseline (`git clone --reference` to mirror) | 2484–2518 | ~3.9 MiB | | PR (`custom-checkout` + `--depth=1 --no-tags`) | 296 + plugin 341 | ~2.1 MiB | **Measured wall-clock savings in the "before yarn" phase: ~15s** (36s → 19s), which comes mostly from skipping the fetch negotiation for tag refs rather than from smaller pack transfer. ### 5. ~~Background CI stats shipping (`post_build_kibana.sh`)~~ — reverted Originally this PR also backgrounded `ship_ci_stats` to overlap it with the artifact upload. Measured savings were only ~0.8–1.4s per build (ship takes ~1s; upload takes ~3.4s), and the pattern introduced a subtle correctness hazard: if `buildkite-agent artifact upload` failed, `set -e` would exit before `wait`, leaving ship as an orphan and swallowing any ship failure. Reverted per review feedback. ### Aggregate timing — Build Kibana Distribution step Baseline average (6 builds) vs PR build #428619, phase-by-phase: | Phase | Baseline avg | PR #428619 | Delta | Attributable to | | --- | --- | --- | --- | --- | | Checkout + setup | 35.8s | 19.1s | **−16.7s** | custom-checkout plugin (this PR) | | Yarn + bootstrap | 51.6s | 6.5s | −45.1s | main commit elastic#262983 (webpack pre-build skip), not this PR | | Docker cleanup (pre-build) | 21.1s | 0.0s | **−21.1s** | backgrounded cleanup (this PR) | | `node scripts/build` | 435.3s | 454.9s | +19.6s | run-to-run variance | | Finalize → archive | 13.1s | 10.0s | **−3.1s** | simplified archive extraction (this PR) | | Ship → upload → end | 4.8s | 3.4s | −1.4s | ~~ship_ci_stats backgrounded~~ (reverted) | | **TOTAL** | **561.6s (9.4 min)** | **493.9s (8.2 min)** | **−67.7s** | | **Savings attributable to this PR in the Build step: ~41s** (21 + 16.7 + 3.1, from docker cleanup bg + custom-checkout + archive simplification). An additional ~32s win comes from a separate main commit (elastic#262983) that landed during this PR's iteration; ~20s is absorbed by build-script variance. The −1.4s on the ship/upload row disappears now that change elastic#5 has been reverted. ### Aggregate per-PR savings | Scope | Savings | | --- | --- | | Build Kibana Distribution step | ~40s wall-clock (critical path) | | ~230 FTR / Scout / Cypress steps × ~33s | ~2 hours aggregate agent-time | ### Build results | Build | Commit | Result | Notes | | --- | --- | --- | --- | | [#428076](https://buildkite.com/elastic/kibana-pull-request/builds/428076) | `d49dc1b` | Passed | 229 FTR configs passed; 3 steps canceled (unrelated GCP disk issue) | | [#428363](https://buildkite.com/elastic/kibana-pull-request/builds/428363) | `9f3edcc` | Passed | 283/284 jobs, 0 test failures | | [#428619](https://buildkite.com/elastic/kibana-pull-request/builds/428619) | `82cad1d` | Passed | 280+ jobs, 0 test failures | ## Test plan - [x] CI "Build Kibana Distribution" step passes — docker cleanup completes before archive, tarball extracts directly to build location - [x] CI stats shipping completes (awaited after artifact upload) - [x] Functional/integration test steps pass — bootstrap and download both succeed when parallelized - [x] Bootstrap failures are correctly propagated (non-zero exit code) - [x] Artifact download failures are correctly propagated - [x] Custom checkout plugin clones the correct commit for the build step --- Made with [Cursor](https://cursor.com); timing tables re-measured from actual Buildkite logs after review feedback. --------- Co-authored-by: Alex Szabo <delanni.alex@gmail.com>

@szwarckonrad

…stic#260544) ## Summary - Migrates the endpoint case attachment from the legacy `ExternalReferenceAttachmentType` to the new unified `UnifiedReferenceAttachmentType` on both client and server. - New endpoint response-action attachments are written as `{ type: 'security.endpoint', attachmentId, metadata }` (`UnifiedReferenceAttachmentPayload`) instead of the legacy `externalReference` shape. - Adds server-side `io-ts` schema validation for endpoint attachment metadata (`command`, `comment`, `targets[]` with a closed union on `agentType`, unknown keys rejected, non-empty `targets` required). - Adds a generic `externalReference` ↔ unified transformer in the Cases plugin so pre-existing legacy endpoint attachments render as unified on read and unified writes fall back to legacy storage when the new SO type is disabled — no data migration required. ## Details Part of the [Cases Attachments v2 migration](elastic/security-team#15569). The endpoint attachment (historically `externalReferenceAttachmentTypeId: 'endpoint'`) is now registered as the unified type `SECURITY_ENDPOINT_ATTACHMENT_TYPE = 'security.endpoint'`, re-exported from `@kbn/cases-plugin/common`. ### What changed | Layer | Before | After | |-------|--------|-------| | Client registration (`security_solution/public/plugin.tsx`) | `registerExternalReference(getExternalReferenceAttachmentEndpointRegular())` | `registerUnified(getEndpointUnifiedAttachment())` | | Server registration (`security_solution/server/plugin.ts`) | `registerExternalReference({ id: CASE_ATTACHMENT_ENDPOINT_TYPE_ID })` | `registerUnified({ id: SECURITY_ENDPOINT_ATTACHMENT_TYPE, schemaValidator: validateEndpointAttachmentMetadata })` | | Attachment creation (`base_response_actions_client.ts`) | `{ type: 'externalReference', externalReferenceId, externalReferenceStorage, externalReferenceAttachmentTypeId: 'endpoint', externalReferenceMetadata }` | `{ type: 'security.endpoint', attachmentId, metadata, owner }` | | Metadata validation | none | `io-ts` validator run on the unified write path | | Client-side renderers | `external_reference.tsx` + 2 lazy wrappers | `unified_attachment.tsx` + updated `endpoint_event.tsx` / `endpoint_children.tsx` | | Constant `CASE_ATTACHMENT_ENDPOINT_TYPE_ID` | defined in Security Solution | removed; import `SECURITY_ENDPOINT_ATTACHMENT_TYPE` from `@kbn/cases-plugin/common` | ### Backward compatibility (no data migration needed) The legacy `registerExternalReference` calls are removed — BWC is delivered instead by a generic transformer in the Cases plugin: - **Read path** — the Kibana Cases UI reads cases via the internal `resolve` endpoint with `mode: 'unified'`. The new `externalReferenceAttachmentTransformer` in `x-pack/platform/plugins/shared/cases/server/common/attachments/external_reference.ts` converts any pre-existing legacy `externalReference` endpoint attachments stored in `cases-comments` into the unified `security.endpoint` shape on read, driven by `EXTERNAL_REFERENCE_TYPE_MAP`. Existing cases render identically post-deploy without any backfill. - **Write path** — when `xpack.cases.attachments.enabled` is `false` (default), the Cases plugin translates the unified payload back to the legacy `externalReference` shape via `toLegacySchema` and persists it to `cases-comments` — byte-for-byte equivalent to today's storage. When the flag is `true`, the unified payload is stored as-is in the new `cases-attachments` SO. Either way, the on-disk format stays consistent with whatever the deployment is already using. This also gives follow-up subtypes (e.g. `osquery`, other response-action types) a clean seam: add an entry to `EXTERNAL_REFERENCE_TYPE_MAP` / `UNIFIED_TO_EXTERNAL_REFERENCE_TYPE_MAP` and they get the same round-trip behaviour for free. ### Public case APIs `GET /api/cases/:id` (`totalComment`) and `GET /api/cases/:id/comments/_find` continue to be scoped to user-generated comments and do not surface endpoint attachments — this is pre-existing, intended behaviour and is unchanged by this PR. The Kibana UI uses the internal `resolve` endpoint which returns all attachment types and renders endpoint attachments via the new unified registry. ## Incremental fixes after first review A second pass addressed three review items from @szwarckonrad on the upgrade-path walkthrough, plus one CI-driven snapshot follow-up. None of them change the design described above; they harden the same migration against edge cases the first pass missed. 1. **Back-compat for legacy-shape API writes** (`security_solution/server/cases/attachments/register.ts` + `plugin.ts`) — the legacy `endpoint` external-reference id is registered alongside the new unified `security.endpoint` so existing API clients that still POST `{ type: 'externalReference', externalReferenceAttachmentTypeId: 'endpoint', ... }` are not rejected with `400 "Attachment type endpoint is not registered."`. The cases server's external-reference transformer already converts these legacy SOs to the unified shape on read; this restores the same behaviour for legacy-shape *writes*. Covered by a focused unit test (`register.test.ts`) that explicitly asserts the BWC registration so it can't be silently dropped in a future refactor. 2. **400 instead of 500 from the metadata validator** (`endpoint_metadata_schema.ts`) — `validateEndpointAttachmentMetadata` now throws `Boom.badRequest` on invalid metadata. Errors thrown from a registered cases-plugin `schemaValidator` callback are surfaced to the HTTP client as-is — a plain `Error` would have bubbled up as `500 Internal Server Error` with a stack trace in the server log for what is really a caller mistake. Covered by new tests asserting `Boom.isBoom` and `statusCode: 400` for null/non-object/missing-fields/empty-targets/unknown-keys inputs. 3. **Byte-clean legacy storage** (`cases/server/services/attachments/index.ts`) — when a unified payload (`{ type: 'security.endpoint', attachmentId, metadata }`) is POSTed but `xpack.cases.attachments.enabled` is OFF, the request attributes still carry those keys after `io-ts` decoding and could leak into `_source` (the `cases-comments` mapping is `dynamic: false`, so they would be stored but not indexed). The new `stripUnifiedOnlyFields` helper guarantees byte-for-byte equivalence with pre-migration legacy writes for `create`/`bulkCreate`/`update`/`bulkUpdate`. Covered by two regression tests in `services/attachments/index.test.ts`. 4. **Snapshot follow-up for #1** (`cases_api_integration/.../external_references.ts`) — the registry-snapshot assertion that guards the externalReference registry now expects `endpoint: 'e13fe41b5c330dd923da91992ed0cedb7e30960f'` again, with an inline comment explaining the BWC intent. **This file is owned by Response Ops via CODEOWNERS** — the snapshot's purpose is exactly to surface this kind of change for their review. CI on the latest push: green (build #437809, 428/428 jobs). ## Test plan - [x] Unit tests for the generic `externalReference` ↔ unified transformer, storage-type resolver, and type-routing helper (`x-pack/platform/plugins/shared/cases/server/common/attachments/*.test.ts`). - [x] Unit tests for `validateEndpointAttachmentMetadata` covering: valid metadata, each missing required field, empty `targets`, invalid `agentType`, unknown top-level keys, and non-object input. - [x] Updated `endpoint_actions_client` and `base_response_actions_client` unit tests assert the new unified payload shape (`type: 'security.endpoint'`, `attachmentId`, `metadata`). - [x] Updated unit tests for `endpoint_event.tsx` / `endpoint_children.tsx` against the unified props shape. - [x] Integration-test registry expectations updated: `security.endpoint` appears in `registered_unified_{basic,trial}.ts`. `endpoint` is **kept** in `external_references.ts` with a comment explaining the back-compat re-registration (see "Incremental fixes after first review" below). - [x] Type check and lint pass. - [x] Manual end-to-end validation against **Microsoft Defender for Endpoint** — unisolate action from Kibana correctly produces a `cases-attachments` SO of `type: 'security.endpoint'` with `microsoft_defender_endpoint` metadata, rendered by the UI via the unified registry. - [x] Manual end-to-end validation against **CrowdStrike Falcon** — unisolate action from Kibana correctly produces a `cases-attachments` SO of `type: 'security.endpoint'` with `crowdstrike` metadata, rendered by the UI via the unified registry. - [x] Manual verification: isolate a host via response actions and confirm the case attachment renders correctly. <img width="1798" height="1064" alt="CleanShot 2026-04-20 at 14 53 16@2x" src="https://github.com/user-attachments/assets/8c216722-a2a4-42ac-b5ae-dc8962cb2d0d" /> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

elastic#270540) ## Release note When using Kibana Spaces, the Synthetics monitor health endpoint could incorrectly report monitors as unhealthy — showing errors such as "missing location", "missing agent policy", or "missing package policy" — even when everything was properly configured. This happened because the health check was only looking for monitors, private locations, and Fleet policies in the current space, missing resources that existed in other spaces. These issues are now fixed: the health check correctly resolves monitors, private locations, package policies, and agent policies across all relevant spaces, giving an accurate health status regardless of how resources are distributed across your Kibana Spaces. ## Summary Closes elastic#270477. `POST /internal/synthetics/monitors/_health` returned wrong results when monitors lived outside the request's space — `missing_package_policy` errors when called from the monitor's space, and 404s when called from `default`. Two independent space-scoping bugs: 1. **Package policy lookup ignored space.** `getExistingPackagePoliciesMap` called Fleet's `packagePolicyService.getByIDs` with `createInternalRepository()`, which is scoped to the default namespace. Package policies created for monitors in another space were therefore invisible. 2. **Monitor saved-object lookup was space-scoped.** `MonitorConfigRepository.get` used the request-scoped saved-objects client, restricted to the request's space. Calling `_health` from `default` for a monitor that lives elsewhere returned a 404. ## What changed - **`PackagePolicyService.getByIds`** — accepts a new optional `additionalSpaceIds`, so the wrapper's per-space scoped-client fan-out can broaden beyond `[spaceId, default]`. Existing callers keep their old behavior. - **`MonitorConfigRepository.getAcrossSpaces(id, namespaces, soClient?)`** — new method that resolves a monitor across an arbitrary list of spaces. Uses the multi-space type's per-object `namespaces` array in one bulkGet entry, plus one entry per namespace for the `namespaceType: 'single'` legacy type. Accepts an injected `soClient` so the health API can pass `createInternalRepository()` and bypass the request's space restriction. - **`MonitorIntegrationHealthApi`**: - Computes `allSpaces = { requestSpace, ...allSpacesWithMonitors }` once, up-front. - `fetchMonitors` calls `monitorConfigRepository.getAcrossSpaces` with the internal repository → fixes bug elastic#2. - `getExistingPackagePoliciesMap` uses the `PackagePolicyService` wrapper with `additionalSpaceIds` → fixes bug #1. ## Test plan - [x] `node scripts/jest` on the three affected suites — **77/77 passing** (includes new cross-space coverage and a new `getAcrossSpaces` test block). - [x] `node scripts/type_check --project x-pack/solutions/observability/plugins/synthetics/tsconfig.json` — clean. - [x] `node scripts/eslint` on the changed files — clean. - [ ] Manual: create a monitor with a private location in a non-default space, then call `POST /internal/synthetics/monitors/_health` both from that space and from `default`. Verify each call reports the monitor accurately instead of `missing_package_policy` / 404. ## Related - elastic#270137 — related health API fix (project monitor policy ID + infinite polling). Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Miguel Martín <miguel.martin@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Fixes elastic#261258 possibly also elastic#264565 (to be verified) ## Summary Add `meta: { id }` to Fleet body/response schemas Files changed: - `server/types/models/agent_policy.ts` — versioned policy schemas (v3–v6), `new_agent_policy`, `agent_policy`, `agent_policy_response`, `full_agent_policy`, outputs responses - `server/types/rest_spec/agent_policy.ts` — bulk get, copy, delete, full policy, K8s manifest, list outputs, cleanup task request/response schemas - `server/types/models/enrollment_api_key.ts `— `enrollment_api_key` - `server/types/rest_spec/enrollment_api_key.ts` — enrollment key CRUD and bulk delete schemas - `common/types/models/package_policy_schema.ts `— all package policy schemas: new, versioned (v22–v24), simplified, update, response, dry-run, status - `server/types/rest_spec/package_policy.ts` — bulk get, create, delete, upgrade, dry-run schemas - `server/types/rest_spec/epm.ts `— ~40 package management schemas (categories, package info/list/stats, install/delete/bulk operations, etc.) - `server/types/rest_spec/agent.ts` — `action_id_response` / `action_message_response` branches of `ActionIdOrMessageSchema` (resolves items #1 and elastic#2 of elastic#264565) ### Testing Verified locally with: ``` node scripts/capture_oas_snapshot --no-serverless --include-path /api/fleet node scripts/validate_oas_docs node scripts/check_api_contracts --distribution stack ``` It looks like there are no Fleet errors left after this change but the final verification step will be ran in the ci for Terraform --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

nreese added 3 commits February 19, 2026 08:47

remove legacy schema and fix transforms

2788d87

remove duplicated types

7a2a8a9

clean up

1f06659

yiannisnikolopoulos merged commit 8f8dad9 into yiannisnikolopoulos:synthetics-embeddable-schema-registration Feb 19, 2026
5 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Synthetics review feedback#1

Synthetics review feedback#1
yiannisnikolopoulos merged 3 commits into
yiannisnikolopoulos:synthetics-embeddable-schema-registrationfrom
nreese:synthetics_review_feedback

nreese commented Feb 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

nreese commented Feb 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants