Commit bfc4162
# Backport
This will backport the following commits from `main` to `9.4`:
- [[ResponseOps] Skip unchanged alerts-as-data component templates and
ILM policy on install
(#278126)](#278126)
<!--- Backport version: 12.0.4 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)
<!--BACKPORT [{"author":{"name":"Ersin
Erdal","email":"92688503+ersin-erdal@users.noreply.github.com"},"sourceCommit":{"committedDate":"2026-08-20T06:59:58Z","message":"[ResponseOps]
Skip unchanged alerts-as-data component templates and ILM policy on
install (#278126)\n\n## Summary\n\nTowards:
https://github.com/elastic/kibana/issues/246016\n\nThe alerts-as-data
(`.alerts-*`) resource installer PUT the ILM policy\nand every component
template **unconditionally on each boot of each\nKibana node**, even
when nothing had changed. Elasticsearch recognises\nan identical PUT and
leaves the cluster state alone, so these writes\nwere not publishing new
cluster states — but the body still crosses the\nwire from every node,
and for component templates the master still\nqueues and runs a
cluster-state update task that parses and compresses\nthe mappings
before concluding nothing changed. Across ~17 resources x N\nnodes on
every boot that is avoidable master work, against the startup\nchurn
behind #246016. (For the ILM policy the no-op check happens before\nany
task is queued, so there the saving is just the request
payload.)\n\nThis stamps a **content hash** into each resource's `_meta`
and\nGET-checks it before writing: on a positive hash match the write
is\nskipped; anything else (missing stamp, 404, error) falls through to
the\nnormal PUT.\n\nThis is the first slice of the \"smarter alert
resource installation\"\nwork (#246016). It intentionally covers the
highest-leverage,\nlowest-risk resources first: the ILM policy and all
component templates\n(including the 83.6 KiB ECS mappings template, by
far the largest).\nIndex templates and the monotonic-version rule are a
deliberate\nfollow-up.\n\n## What changed\n\n-
New\n[`resource_hash.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/alerts_service/lib/resource_hash.ts):\n`computeResourceHash(body)`
— a deterministic hash (recursively sorted\nkeys, `undefined` dropped,
array order preserved) via Node `crypto` +\nSHA-256, plus the
`_meta.content_hash` field name. No new dependency.\n-
`create_or_update_component_template.ts` — stamps
`_meta.content_hash`\n(computed over the template body, excluding
`_meta`), GETs the installed\ntemplate, and skips the PUT on a hash
match. The existing field-limit\nfailure/retry path is untouched; it
only runs when we actually PUT.\n- `create_or_update_ilm_policy.ts` —
same pattern, hashing the policy\nbody (excluding `_meta`).\n- Because
`createOrUpdateComponentTemplate` is shared with the\n`rule_registry`
`ResourceInstaller` and covers both common and context\ncomponent
templates, all of them benefit from the same change.\n\n### Fail-safe by
design\n\nSkipping happens **only** on a positive hash match. A 404, a
missing\nstamp (resources installed before this change), or any GET
failure —\npermissions, an exhausted retry — leaves the installed
content unknown\nand falls through to the normal PUT, so the check can
never block an\ninstall that would otherwise have succeeded. The worst
case is today's\nbehavior: a redundant write.\n\nOne deliberate behavior
change: the skip keys off the stamp, not the\nlive body. If someone
hand-edits a managed `.alerts-*` resource but\nleaves
`_meta.content_hash` intact, Kibana keeps skipping it, where\nbefore
this PR every boot silently repaired the drift. Any edit that\nalso
drops or changes `_meta.content_hash` still converges on the next\nboot.
For framework-managed `.alerts-*` resources that trade seems\nright, but
it is a real change and not covered by \"never a
missed\nupdate\".\n\n### Effect\n\nOn a no-change restart, the three
shared component templates + the ILM\npolicy collapse from unconditional
PUTs to one cheap GET each, per node.\nFirst boot, version upgrades
(field maps change → hash changes), and\nmanual edits that touch `_meta`
all still PUT.\n\n## How to test manually\n\nThe change makes installs
**skip the write when nothing changed**, so\nthe thing to verify is
*behavior* (skipped vs written), not a settings\nvalue. The signals are
the Kibana debug log, the `_meta.content_hash`\nstamp, and — for
component templates — the Elasticsearch master log.\n\n### Setup\n- Run
ES with `path.data=../your-local-data-path` so resources
survive\nrestarts.\n- Enable debug logging for alerting in
`kibana.yml`:\n ```yaml\n logging.loggers:\n - name: plugins.alerting\n
level: debug\n ```\n\n### Test 1 — first install stamps the content
hash\n1. Start ES + Kibana on a clean data path.\n2. In Dev Tools,
confirm the shared resources exist and each carries a\nstamp:\n ```\nGET
_component_template/.alerts-framework-mappings →
_meta.content_hash\npresent\nGET
_component_template/.alerts-legacy-alert-mappings →\n_meta.content_hash
present\nGET _component_template/.alerts-ecs-mappings →
_meta.content_hash\npresent\nGET _ilm/policy/.alerts-ilm-policy →
_meta.content_hash present\n ```\n\n### Test 2 — no-change restart skips
every write (the fix)\n1. Stop Kibana, restart with no code/config
change.\n2. Logs show a skip line per resource:\n ```\nSkipping install
of component template .alerts-framework-mappings;\ncontent unchanged
(<hash>)\nSkipping install of ILM policy .alerts-ilm-policy; content
unchanged\n(<hash>)\n ```\n3. Note that the ILM policy `version` is
**not** a useful signal here:\nElasticsearch no-ops an identical
`putLifecycle`, so `version` stays put\non `main` too. The Kibana debug
lines above are the discriminator. For\ncomponent templates you can
corroborate on the Elasticsearch side: the\nmaster logs `updating
component template [...]` at INFO only when the\ncontent actually
differs, so on `main` that line appears on every boot\nand here it does
not.\n4. On `main` all four are PUT on every boot (and discarded by ES
as\nno-ops); here the request is never sent.\n\n### Test 3 — a real
change still installs, at per-resource granularity\n1. Force a
component-template change: add a field to a rule
type's\n`alerts.mappings` (e.g. the custom threshold rule type, per the
fixture\nin #216719).\n2. Restart Kibana.\n3. Logs show the affected
component template **installing** (no skip\nline), while unchanged
resources (ILM policy, legacy-alert template)\nstill skip.\n4. `GET
_component_template/<changed-template>` → `_meta.content_hash`\ndiffers
from Test 1.\n\n### Test 4 — pre-upgrade resources (no stamp) install
once, then skip\n1. Simulate a resource installed before this change by
removing\n`_meta.content_hash` from one template and PUTting it
back.\n2. Restart Kibana → that template **installs** (missing stamp
→\nfail-safe PUT, re-adds the hash).\n3. Restart again → now it
**skips**. Confirms unstamped resources\nconverge rather than being
skipped incorrectly.\n\n### Test 5 — data streams (serverless path)\n1.
Run with serverless config (`useDataStreamForAlerts` true).\n2. Repeat
Test 2. The ILM policy is skipped entirely as before (early\nreturn on
data streams); component templates skip on a no-change restart\nexactly
as in stateful mode.\n\n## Testing\n\n- `node
scripts/jest\nx-pack/platform/plugins/shared/alerting/server/alerts_service`
— new\n`resource_hash` suite + updated
`create_or_update_component_template` /\n`create_or_update_ilm_policy`
suites (skip-on-match, PUT-on-change,\nPUT-on-404/missing-stamp,
PUT-when-unreadable), and\n`alerts_service.test.ts` all pass.\n- `node
scripts/jest\nx-pack/platform/plugins/shared/rule_registry/server/rule_data_plugin_service`\n—
pass.\n- scoped type check and eslint clean.\n\n## Notes /
follow-ups\n\n- **Scope:** index templates
(`createOrUpdateIndexTemplate`) are\nintentionally not included — that
path carries the field-limit\npreservation logic and always-PUT
(composed_of + simulate) semantics\nthat need separate handling.
Follow-up in #280154.\n- **Kill switch:** none added; the fail-safe
design keeps the risk low.\nHappy to add a `skipUnchangedResources`
config opt-out if reviewers\nprefer an escape hatch.\n-
**Observability:** a `puts_skipped` / `puts_executed` metric (phase
0\nof #246016) would make the skip observable in production and is the
only\nway to demonstrate the saving in a real deployment. Planned as
a\nseparate change alongside the index-template slice.\n\nContributes to
#246016\n\n🤖 Generated with [Claude
Code](https://claude.com/claude-code)\n\n---------\n\nCo-authored-by:
Claude Opus 4.8 <noreply@anthropic.com>\nCo-authored-by: Cursor
<cursoragent@cursor.com>","sha":"2c8f0181e11a512e95659bad6b99916d908a7d87","branchLabelMapping":{"^v9.6.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","backport:skip","Team:ResponseOps","v9.6.0"],"title":"[ResponseOps]
Skip unchanged alerts-as-data component templates and ILM policy on
install","number":278126,"url":"https://github.com/elastic/kibana/pull/278126","mergeCommit":{"message":"[ResponseOps]
Skip unchanged alerts-as-data component templates and ILM policy on
install (#278126)\n\n## Summary\n\nTowards:
https://github.com/elastic/kibana/issues/246016\n\nThe alerts-as-data
(`.alerts-*`) resource installer PUT the ILM policy\nand every component
template **unconditionally on each boot of each\nKibana node**, even
when nothing had changed. Elasticsearch recognises\nan identical PUT and
leaves the cluster state alone, so these writes\nwere not publishing new
cluster states — but the body still crosses the\nwire from every node,
and for component templates the master still\nqueues and runs a
cluster-state update task that parses and compresses\nthe mappings
before concluding nothing changed. Across ~17 resources x N\nnodes on
every boot that is avoidable master work, against the startup\nchurn
behind #246016. (For the ILM policy the no-op check happens before\nany
task is queued, so there the saving is just the request
payload.)\n\nThis stamps a **content hash** into each resource's `_meta`
and\nGET-checks it before writing: on a positive hash match the write
is\nskipped; anything else (missing stamp, 404, error) falls through to
the\nnormal PUT.\n\nThis is the first slice of the \"smarter alert
resource installation\"\nwork (#246016). It intentionally covers the
highest-leverage,\nlowest-risk resources first: the ILM policy and all
component templates\n(including the 83.6 KiB ECS mappings template, by
far the largest).\nIndex templates and the monotonic-version rule are a
deliberate\nfollow-up.\n\n## What changed\n\n-
New\n[`resource_hash.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/alerts_service/lib/resource_hash.ts):\n`computeResourceHash(body)`
— a deterministic hash (recursively sorted\nkeys, `undefined` dropped,
array order preserved) via Node `crypto` +\nSHA-256, plus the
`_meta.content_hash` field name. No new dependency.\n-
`create_or_update_component_template.ts` — stamps
`_meta.content_hash`\n(computed over the template body, excluding
`_meta`), GETs the installed\ntemplate, and skips the PUT on a hash
match. The existing field-limit\nfailure/retry path is untouched; it
only runs when we actually PUT.\n- `create_or_update_ilm_policy.ts` —
same pattern, hashing the policy\nbody (excluding `_meta`).\n- Because
`createOrUpdateComponentTemplate` is shared with the\n`rule_registry`
`ResourceInstaller` and covers both common and context\ncomponent
templates, all of them benefit from the same change.\n\n### Fail-safe by
design\n\nSkipping happens **only** on a positive hash match. A 404, a
missing\nstamp (resources installed before this change), or any GET
failure —\npermissions, an exhausted retry — leaves the installed
content unknown\nand falls through to the normal PUT, so the check can
never block an\ninstall that would otherwise have succeeded. The worst
case is today's\nbehavior: a redundant write.\n\nOne deliberate behavior
change: the skip keys off the stamp, not the\nlive body. If someone
hand-edits a managed `.alerts-*` resource but\nleaves
`_meta.content_hash` intact, Kibana keeps skipping it, where\nbefore
this PR every boot silently repaired the drift. Any edit that\nalso
drops or changes `_meta.content_hash` still converges on the next\nboot.
For framework-managed `.alerts-*` resources that trade seems\nright, but
it is a real change and not covered by \"never a
missed\nupdate\".\n\n### Effect\n\nOn a no-change restart, the three
shared component templates + the ILM\npolicy collapse from unconditional
PUTs to one cheap GET each, per node.\nFirst boot, version upgrades
(field maps change → hash changes), and\nmanual edits that touch `_meta`
all still PUT.\n\n## How to test manually\n\nThe change makes installs
**skip the write when nothing changed**, so\nthe thing to verify is
*behavior* (skipped vs written), not a settings\nvalue. The signals are
the Kibana debug log, the `_meta.content_hash`\nstamp, and — for
component templates — the Elasticsearch master log.\n\n### Setup\n- Run
ES with `path.data=../your-local-data-path` so resources
survive\nrestarts.\n- Enable debug logging for alerting in
`kibana.yml`:\n ```yaml\n logging.loggers:\n - name: plugins.alerting\n
level: debug\n ```\n\n### Test 1 — first install stamps the content
hash\n1. Start ES + Kibana on a clean data path.\n2. In Dev Tools,
confirm the shared resources exist and each carries a\nstamp:\n ```\nGET
_component_template/.alerts-framework-mappings →
_meta.content_hash\npresent\nGET
_component_template/.alerts-legacy-alert-mappings →\n_meta.content_hash
present\nGET _component_template/.alerts-ecs-mappings →
_meta.content_hash\npresent\nGET _ilm/policy/.alerts-ilm-policy →
_meta.content_hash present\n ```\n\n### Test 2 — no-change restart skips
every write (the fix)\n1. Stop Kibana, restart with no code/config
change.\n2. Logs show a skip line per resource:\n ```\nSkipping install
of component template .alerts-framework-mappings;\ncontent unchanged
(<hash>)\nSkipping install of ILM policy .alerts-ilm-policy; content
unchanged\n(<hash>)\n ```\n3. Note that the ILM policy `version` is
**not** a useful signal here:\nElasticsearch no-ops an identical
`putLifecycle`, so `version` stays put\non `main` too. The Kibana debug
lines above are the discriminator. For\ncomponent templates you can
corroborate on the Elasticsearch side: the\nmaster logs `updating
component template [...]` at INFO only when the\ncontent actually
differs, so on `main` that line appears on every boot\nand here it does
not.\n4. On `main` all four are PUT on every boot (and discarded by ES
as\nno-ops); here the request is never sent.\n\n### Test 3 — a real
change still installs, at per-resource granularity\n1. Force a
component-template change: add a field to a rule
type's\n`alerts.mappings` (e.g. the custom threshold rule type, per the
fixture\nin #216719).\n2. Restart Kibana.\n3. Logs show the affected
component template **installing** (no skip\nline), while unchanged
resources (ILM policy, legacy-alert template)\nstill skip.\n4. `GET
_component_template/<changed-template>` → `_meta.content_hash`\ndiffers
from Test 1.\n\n### Test 4 — pre-upgrade resources (no stamp) install
once, then skip\n1. Simulate a resource installed before this change by
removing\n`_meta.content_hash` from one template and PUTting it
back.\n2. Restart Kibana → that template **installs** (missing stamp
→\nfail-safe PUT, re-adds the hash).\n3. Restart again → now it
**skips**. Confirms unstamped resources\nconverge rather than being
skipped incorrectly.\n\n### Test 5 — data streams (serverless path)\n1.
Run with serverless config (`useDataStreamForAlerts` true).\n2. Repeat
Test 2. The ILM policy is skipped entirely as before (early\nreturn on
data streams); component templates skip on a no-change restart\nexactly
as in stateful mode.\n\n## Testing\n\n- `node
scripts/jest\nx-pack/platform/plugins/shared/alerting/server/alerts_service`
— new\n`resource_hash` suite + updated
`create_or_update_component_template` /\n`create_or_update_ilm_policy`
suites (skip-on-match, PUT-on-change,\nPUT-on-404/missing-stamp,
PUT-when-unreadable), and\n`alerts_service.test.ts` all pass.\n- `node
scripts/jest\nx-pack/platform/plugins/shared/rule_registry/server/rule_data_plugin_service`\n—
pass.\n- scoped type check and eslint clean.\n\n## Notes /
follow-ups\n\n- **Scope:** index templates
(`createOrUpdateIndexTemplate`) are\nintentionally not included — that
path carries the field-limit\npreservation logic and always-PUT
(composed_of + simulate) semantics\nthat need separate handling.
Follow-up in #280154.\n- **Kill switch:** none added; the fail-safe
design keeps the risk low.\nHappy to add a `skipUnchangedResources`
config opt-out if reviewers\nprefer an escape hatch.\n-
**Observability:** a `puts_skipped` / `puts_executed` metric (phase
0\nof #246016) would make the skip observable in production and is the
only\nway to demonstrate the saving in a real deployment. Planned as
a\nseparate change alongside the index-template slice.\n\nContributes to
#246016\n\n🤖 Generated with [Claude
Code](https://claude.com/claude-code)\n\n---------\n\nCo-authored-by:
Claude Opus 4.8 <noreply@anthropic.com>\nCo-authored-by: Cursor
<cursoragent@cursor.com>","sha":"2c8f0181e11a512e95659bad6b99916d908a7d87"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.6.0","branchLabelMappingKey":"^v9.6.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/278126","number":278126,"mergeCommit":{"message":"[ResponseOps]
Skip unchanged alerts-as-data component templates and ILM policy on
install (#278126)\n\n## Summary\n\nTowards:
https://github.com/elastic/kibana/issues/246016\n\nThe alerts-as-data
(`.alerts-*`) resource installer PUT the ILM policy\nand every component
template **unconditionally on each boot of each\nKibana node**, even
when nothing had changed. Elasticsearch recognises\nan identical PUT and
leaves the cluster state alone, so these writes\nwere not publishing new
cluster states — but the body still crosses the\nwire from every node,
and for component templates the master still\nqueues and runs a
cluster-state update task that parses and compresses\nthe mappings
before concluding nothing changed. Across ~17 resources x N\nnodes on
every boot that is avoidable master work, against the startup\nchurn
behind #246016. (For the ILM policy the no-op check happens before\nany
task is queued, so there the saving is just the request
payload.)\n\nThis stamps a **content hash** into each resource's `_meta`
and\nGET-checks it before writing: on a positive hash match the write
is\nskipped; anything else (missing stamp, 404, error) falls through to
the\nnormal PUT.\n\nThis is the first slice of the \"smarter alert
resource installation\"\nwork (#246016). It intentionally covers the
highest-leverage,\nlowest-risk resources first: the ILM policy and all
component templates\n(including the 83.6 KiB ECS mappings template, by
far the largest).\nIndex templates and the monotonic-version rule are a
deliberate\nfollow-up.\n\n## What changed\n\n-
New\n[`resource_hash.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/alerts_service/lib/resource_hash.ts):\n`computeResourceHash(body)`
— a deterministic hash (recursively sorted\nkeys, `undefined` dropped,
array order preserved) via Node `crypto` +\nSHA-256, plus the
`_meta.content_hash` field name. No new dependency.\n-
`create_or_update_component_template.ts` — stamps
`_meta.content_hash`\n(computed over the template body, excluding
`_meta`), GETs the installed\ntemplate, and skips the PUT on a hash
match. The existing field-limit\nfailure/retry path is untouched; it
only runs when we actually PUT.\n- `create_or_update_ilm_policy.ts` —
same pattern, hashing the policy\nbody (excluding `_meta`).\n- Because
`createOrUpdateComponentTemplate` is shared with the\n`rule_registry`
`ResourceInstaller` and covers both common and context\ncomponent
templates, all of them benefit from the same change.\n\n### Fail-safe by
design\n\nSkipping happens **only** on a positive hash match. A 404, a
missing\nstamp (resources installed before this change), or any GET
failure —\npermissions, an exhausted retry — leaves the installed
content unknown\nand falls through to the normal PUT, so the check can
never block an\ninstall that would otherwise have succeeded. The worst
case is today's\nbehavior: a redundant write.\n\nOne deliberate behavior
change: the skip keys off the stamp, not the\nlive body. If someone
hand-edits a managed `.alerts-*` resource but\nleaves
`_meta.content_hash` intact, Kibana keeps skipping it, where\nbefore
this PR every boot silently repaired the drift. Any edit that\nalso
drops or changes `_meta.content_hash` still converges on the next\nboot.
For framework-managed `.alerts-*` resources that trade seems\nright, but
it is a real change and not covered by \"never a
missed\nupdate\".\n\n### Effect\n\nOn a no-change restart, the three
shared component templates + the ILM\npolicy collapse from unconditional
PUTs to one cheap GET each, per node.\nFirst boot, version upgrades
(field maps change → hash changes), and\nmanual edits that touch `_meta`
all still PUT.\n\n## How to test manually\n\nThe change makes installs
**skip the write when nothing changed**, so\nthe thing to verify is
*behavior* (skipped vs written), not a settings\nvalue. The signals are
the Kibana debug log, the `_meta.content_hash`\nstamp, and — for
component templates — the Elasticsearch master log.\n\n### Setup\n- Run
ES with `path.data=../your-local-data-path` so resources
survive\nrestarts.\n- Enable debug logging for alerting in
`kibana.yml`:\n ```yaml\n logging.loggers:\n - name: plugins.alerting\n
level: debug\n ```\n\n### Test 1 — first install stamps the content
hash\n1. Start ES + Kibana on a clean data path.\n2. In Dev Tools,
confirm the shared resources exist and each carries a\nstamp:\n ```\nGET
_component_template/.alerts-framework-mappings →
_meta.content_hash\npresent\nGET
_component_template/.alerts-legacy-alert-mappings →\n_meta.content_hash
present\nGET _component_template/.alerts-ecs-mappings →
_meta.content_hash\npresent\nGET _ilm/policy/.alerts-ilm-policy →
_meta.content_hash present\n ```\n\n### Test 2 — no-change restart skips
every write (the fix)\n1. Stop Kibana, restart with no code/config
change.\n2. Logs show a skip line per resource:\n ```\nSkipping install
of component template .alerts-framework-mappings;\ncontent unchanged
(<hash>)\nSkipping install of ILM policy .alerts-ilm-policy; content
unchanged\n(<hash>)\n ```\n3. Note that the ILM policy `version` is
**not** a useful signal here:\nElasticsearch no-ops an identical
`putLifecycle`, so `version` stays put\non `main` too. The Kibana debug
lines above are the discriminator. For\ncomponent templates you can
corroborate on the Elasticsearch side: the\nmaster logs `updating
component template [...]` at INFO only when the\ncontent actually
differs, so on `main` that line appears on every boot\nand here it does
not.\n4. On `main` all four are PUT on every boot (and discarded by ES
as\nno-ops); here the request is never sent.\n\n### Test 3 — a real
change still installs, at per-resource granularity\n1. Force a
component-template change: add a field to a rule
type's\n`alerts.mappings` (e.g. the custom threshold rule type, per the
fixture\nin #216719).\n2. Restart Kibana.\n3. Logs show the affected
component template **installing** (no skip\nline), while unchanged
resources (ILM policy, legacy-alert template)\nstill skip.\n4. `GET
_component_template/<changed-template>` → `_meta.content_hash`\ndiffers
from Test 1.\n\n### Test 4 — pre-upgrade resources (no stamp) install
once, then skip\n1. Simulate a resource installed before this change by
removing\n`_meta.content_hash` from one template and PUTting it
back.\n2. Restart Kibana → that template **installs** (missing stamp
→\nfail-safe PUT, re-adds the hash).\n3. Restart again → now it
**skips**. Confirms unstamped resources\nconverge rather than being
skipped incorrectly.\n\n### Test 5 — data streams (serverless path)\n1.
Run with serverless config (`useDataStreamForAlerts` true).\n2. Repeat
Test 2. The ILM policy is skipped entirely as before (early\nreturn on
data streams); component templates skip on a no-change restart\nexactly
as in stateful mode.\n\n## Testing\n\n- `node
scripts/jest\nx-pack/platform/plugins/shared/alerting/server/alerts_service`
— new\n`resource_hash` suite + updated
`create_or_update_component_template` /\n`create_or_update_ilm_policy`
suites (skip-on-match, PUT-on-change,\nPUT-on-404/missing-stamp,
PUT-when-unreadable), and\n`alerts_service.test.ts` all pass.\n- `node
scripts/jest\nx-pack/platform/plugins/shared/rule_registry/server/rule_data_plugin_service`\n—
pass.\n- scoped type check and eslint clean.\n\n## Notes /
follow-ups\n\n- **Scope:** index templates
(`createOrUpdateIndexTemplate`) are\nintentionally not included — that
path carries the field-limit\npreservation logic and always-PUT
(composed_of + simulate) semantics\nthat need separate handling.
Follow-up in #280154.\n- **Kill switch:** none added; the fail-safe
design keeps the risk low.\nHappy to add a `skipUnchangedResources`
config opt-out if reviewers\nprefer an escape hatch.\n-
**Observability:** a `puts_skipped` / `puts_executed` metric (phase
0\nof #246016) would make the skip observable in production and is the
only\nway to demonstrate the saving in a real deployment. Planned as
a\nseparate change alongside the index-template slice.\n\nContributes to
#246016\n\n🤖 Generated with [Claude
Code](https://claude.com/claude-code)\n\n---------\n\nCo-authored-by:
Claude Opus 4.8 <noreply@anthropic.com>\nCo-authored-by: Cursor
<cursoragent@cursor.com>","sha":"2c8f0181e11a512e95659bad6b99916d908a7d87"}}]}]
BACKPORT-->
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
1 parent d2fbd27 commit bfc4162
8 files changed
Lines changed: 396 additions & 17 deletions
File tree
- x-pack/platform
- test/alerting_api_integration/spaces_only/tests/alerting/group4/alerts_as_data
Lines changed: 1 addition & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
110 | 110 | | |
111 | 111 | | |
112 | 112 | | |
| 113 | + | |
113 | 114 | | |
114 | 115 | | |
115 | 116 | | |
| |||
Lines changed: 97 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
42 | 42 | | |
43 | 43 | | |
44 | 44 | | |
45 | | - | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
| 88 | + | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | + | |
| 98 | + | |
| 99 | + | |
| 100 | + | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
| 106 | + | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
| 115 | + | |
| 116 | + | |
| 117 | + | |
| 118 | + | |
| 119 | + | |
| 120 | + | |
| 121 | + | |
| 122 | + | |
| 123 | + | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
46 | 136 | | |
47 | 137 | | |
48 | 138 | | |
49 | 139 | | |
50 | 140 | | |
51 | 141 | | |
52 | 142 | | |
53 | | - | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
54 | 149 | | |
55 | 150 | | |
56 | 151 | | |
| |||
Lines changed: 57 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
13 | 13 | | |
14 | 14 | | |
15 | 15 | | |
| 16 | + | |
16 | 17 | | |
17 | 18 | | |
18 | 19 | | |
| |||
21 | 22 | | |
22 | 23 | | |
23 | 24 | | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
24 | 54 | | |
25 | 55 | | |
26 | 56 | | |
| |||
108 | 138 | | |
109 | 139 | | |
110 | 140 | | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
| 151 | + | |
| 152 | + | |
111 | 153 | | |
112 | | - | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
| 158 | + | |
| 159 | + | |
| 160 | + | |
| 161 | + | |
| 162 | + | |
| 163 | + | |
| 164 | + | |
| 165 | + | |
| 166 | + | |
| 167 | + | |
| 168 | + | |
113 | 169 | | |
114 | 170 | | |
115 | 171 | | |
| |||
Lines changed: 87 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
36 | 36 | | |
37 | 37 | | |
38 | 38 | | |
39 | | - | |
| 39 | + | |
40 | 40 | | |
41 | 41 | | |
42 | 42 | | |
| |||
46 | 46 | | |
47 | 47 | | |
48 | 48 | | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
| 88 | + | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | + | |
| 98 | + | |
| 99 | + | |
| 100 | + | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
| 106 | + | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
49 | 115 | | |
50 | 116 | | |
| 117 | + | |
51 | 118 | | |
| 119 | + | |
| 120 | + | |
| 121 | + | |
| 122 | + | |
| 123 | + | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
| 137 | + | |
52 | 138 | | |
53 | 139 | | |
54 | 140 | | |
| |||
Lines changed: 51 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
| 10 | + | |
10 | 11 | | |
11 | 12 | | |
| 13 | + | |
12 | 14 | | |
13 | 15 | | |
14 | 16 | | |
| |||
17 | 19 | | |
18 | 20 | | |
19 | 21 | | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
20 | 50 | | |
21 | 51 | | |
22 | 52 | | |
| |||
31 | 61 | | |
32 | 62 | | |
33 | 63 | | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
34 | 75 | | |
35 | | - | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
36 | 86 | | |
37 | 87 | | |
38 | 88 | | |
| |||
0 commit comments