[ResponseOps][Alerting v2] Move episodes time filter inside query, include previous actions

[umbopepato]

📄 Summary

Important

Alerting v2 work under feature flag disabled by default. See 🧪 Verification steps > ⚙️ Environment Setup for more information.

• Applies the time picker range to the alert events only. Until now the range filtered every document before the aggregations ran, so an episode lost its actions-derived metadata (tags, ack, assignee and snooze) if those actions were outside the time range, and its duration only covered the part inside the range.
• Marks the duration with a gte symbol (≥ 14 min, with a tooltip) when the episode started before the range, since first_timestamp cannot be outside the range. The flyout still shows the full value.
  ⚠️ This is a compromise solution to keep the query performant. All other solutions that queried unbounded rule-events to look for the episode start event were painfully slow (~1min load time on a local setup with around 70 episodes across 1 day of activity). More in 🧰 Implementation details

🧪 Verification steps

⚙️ Environment Setup

Add the following flag to your kibana.dev.yml:

xpack.alerting_v2.enabled: true

Then navigate to Stack Management > Advanced settings > Global, and enable Alerting v2

You need an episode that has been active for a while (i.e. more than an hour), with a tag and an ack added shortly after it started.

✅ Happy Path

1. Open the episodes list with Last 15 minutes selected
2. The episode row shows its tags and the ack indicator
3. The duration cell shows ≥ followed by the duration seen inside the range, and hovering it explains why
4. Widen the range to include the episode start: the ≥ goes away and the duration becomes the full one

⚡️ Edge Cases

1. Open the flyout of a ≥ row: it shows the full duration and the same tags and ack
2. The acknowledged and snoozed KPIs count the episode on the short range too
3. Filtering by one of its tags still returns the episode on the short range

🐞 Known issues & potential improvements

• The duration is still clamped to the range, but at least it's flagged with a symbol and explanation in the cell. To make it exact at the same cost some work on the data itself is necessary. I.E. have the director write the episode start on each event.
• Rules with pending_count: 0 skip the pending state, so when no earlier episode of the same series is in range we can't tell whether we saw the start, and the row shows ≥ even when the duration is exact.
• The $.alert-episodes view has the same aggregation shape and Discover pushes its own range down, so the profile is not covered by this change.

🧰 Implementation details

The range is sent as a request filter (bool.should: [type == "alert" AND range, exists(action_type)]) through input.filters instead of the esql function's timeField, so ES still bounds the .rule-events scan at the Lucene level and every .alert-actions doc passes. Measured on 2M events at 12h: 0.18s vs 0.11s before.

I first tried selecting the episodes in range with an IN (subquery) and aggregating their full history (@adcoelho's suggestion), to fix the duration too. ES does not push the subquery down: 28s on the same data. A literal id list is pushed down (0.3s), but that means two requests.

📷 Screenshots

⏪ Backport rationale

Alerting v2 pre-GA work, not backporting

🔗 References

Fixes https://github.com/elastic/rna-program/issues/1030

🤖 PR Co-authored by Claude Code

☑️ Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• Flaky Test Runner was used on any tests changed
• Review the backport guidelines and apply applicable backport:* labels.

[infra-vault-gh-plugin-prod]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!
• Click to trigger kibana-deploy-project-from-pr for this PR!
• Click to trigger kibana-deploy-cloud-from-pr for this PR!
• Click to trigger kibana-entity-store-performance-from-pr for this PR!
• Click to trigger kibana-storybooks-from-pr for this PR!

[kibanamachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 43ca950
• Build duration: 54 mins

Failed CI Steps

• Jest Tests #10
• Serverless Rule Management - Prebuilt Rules Upgrade - Security Solution Cypress Tests #1

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
alertingVTwo	864.9KB	868.0KB	+3.0KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
shared-packages	4.6MB	4.6MB	+60.0B

Unknown metric groups

total optimizer output size

id	before	after	diff
all	63.9MB	63.9MB	+3.1KB

warm start memory

id	before	after	diff
post forced gc heap baseline	-	836903674	+836903674
post forced gc heap delta	-	-2094696	-2094696
post forced gc heap delta standard deviation	-	1980151	+1980151
post forced gc heap target	-	834808978	+834808978
tail heap delta	-	-23635938	-23635938
total			+1647962169

[infra-vault-gh-plugin-prod]

Pinging @elastic/response-ops (Team:ResponseOps)