[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params #217440
Conversation
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
cnasikas
added
bug
cnasikas
changed the title
|
/ci |
|
Pinging @elastic/response-ops (Team:ResponseOps) |
cnasikas
added
the
release_note:skip
cnasikas
commented
Apr 8, 2025
|
|
||
| const countRuleParamsSchema = schema.intersection([ | ||
| schema.object({ | ||
| const countRuleParamsSchema = schema.object( |
There was a problem hiding this comment.
I had to duplicate the schema to be able to use { unknowns: 'ignore' } on the top level. schema.intersection does not support { unknowns: 'ignore' }.
adcoelho
reviewed
Apr 8, 2025
|
|
||
| it('strips out excess fields', () => { | ||
| const result = logThresholdParamsSchema.validate(countParams); | ||
| expect(result).toEqual(omit(countParams, 'outputIndex')); |
There was a problem hiding this comment.
countParams does not have outputIndex. Adding countParamsWithExcess here would make this test a duplicate, maybe we want to remove it?
adcoelho
reviewed
Apr 8, 2025
| ], | ||
| }; | ||
|
|
||
| const rationParams = { |
There was a problem hiding this comment.
ratioRuleParamsSchema was also changed to include { unknowns: 'ignore' } we could add a ratioParamsWithExcess and a 'validates ratio params correctly'.
Also, I think there is a typo:
Suggested change
| const rationParams = { | |
| const ratioParams = { |
js-jankisalvi
approved these changes
Apr 8, 2025
adcoelho
reviewed
Apr 8, 2025
There was a problem hiding this comment.
A few objects in log_threshold/v1 have now { unknowns: 'ignore' }. The naming is confusing but I think we do not test that count: ThresholdSchema, does not break with additional fields. (We only test criteria: countCriteriaSchema, with countParams(WithExcess).)
ymao1
approved these changes
Apr 8, 2025
guskovaue
approved these changes
Apr 8, 2025
|
Starting backport for target branches: 8.18, 8.x, 9.0 |
💚 Build Succeeded
Metrics [docs]
History
cc @cnasikas |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Apr 8, 2025
…ld params (elastic#217440) ## Summary A PR introduced into 8.18/9.0 (elastic#205507) changed the way we validate the log threshold rule type parameters. The validation happens on rule params and changes a loose validation to a strict validation, so those users who’ve inserted excess fields before 8.18/9.0 will see rules starting to fail to run, their rule page failing to load and the API starting to reject calls with excess fields. Fixes: elastic#217384 ## Testing instructions 1. Start Kibana on 8.17 and create the following rule using the API. Let the rule run. <details><summary>Rule</summary> ``` { "name": "[QAF] Observability rule 3", "tags": [ "metrics", "threshold", "qaf" ], "rule_type_id": "logs.alert.document.count", "consumer": "alerts", "schedule": { "interval": "1m" }, "actions": [], "params": { "timeSize": 8, "timeUnit": "h", "count": { "value": 1, "comparator": "more than" }, "criteria": [ { "field": "bytes", "comparator": "more than", "value": 1 } ], "logView": { "logViewId": "log-view-reference-0", "type": "log-view-reference" }, "groupBy": [ "geo.dest" ], "outputIndex": ".alerts-observability.logs.alerts-default" } } ``` </details> 2. Start Kibana on 8.18. Verify that you cannot create the same rule and the rule created in step 1 starts failing. 3. Start Kibana on this PR and that you can create the same rule and the rule created in step 1 is working as expected. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 (cherry picked from commit 2a01722)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Apr 8, 2025
…ld params (elastic#217440) ## Summary A PR introduced into 8.18/9.0 (elastic#205507) changed the way we validate the log threshold rule type parameters. The validation happens on rule params and changes a loose validation to a strict validation, so those users who’ve inserted excess fields before 8.18/9.0 will see rules starting to fail to run, their rule page failing to load and the API starting to reject calls with excess fields. Fixes: elastic#217384 ## Testing instructions 1. Start Kibana on 8.17 and create the following rule using the API. Let the rule run. <details><summary>Rule</summary> ``` { "name": "[QAF] Observability rule 3", "tags": [ "metrics", "threshold", "qaf" ], "rule_type_id": "logs.alert.document.count", "consumer": "alerts", "schedule": { "interval": "1m" }, "actions": [], "params": { "timeSize": 8, "timeUnit": "h", "count": { "value": 1, "comparator": "more than" }, "criteria": [ { "field": "bytes", "comparator": "more than", "value": 1 } ], "logView": { "logViewId": "log-view-reference-0", "type": "log-view-reference" }, "groupBy": [ "geo.dest" ], "outputIndex": ".alerts-observability.logs.alerts-default" } } ``` </details> 2. Start Kibana on 8.18. Verify that you cannot create the same rule and the rule created in step 1 starts failing. 3. Start Kibana on this PR and that you can create the same rule and the rule created in step 1 is working as expected. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 (cherry picked from commit 2a01722)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Apr 8, 2025
…ld params (elastic#217440) ## Summary A PR introduced into 8.18/9.0 (elastic#205507) changed the way we validate the log threshold rule type parameters. The validation happens on rule params and changes a loose validation to a strict validation, so those users who’ve inserted excess fields before 8.18/9.0 will see rules starting to fail to run, their rule page failing to load and the API starting to reject calls with excess fields. Fixes: elastic#217384 ## Testing instructions 1. Start Kibana on 8.17 and create the following rule using the API. Let the rule run. <details><summary>Rule</summary> ``` { "name": "[QAF] Observability rule 3", "tags": [ "metrics", "threshold", "qaf" ], "rule_type_id": "logs.alert.document.count", "consumer": "alerts", "schedule": { "interval": "1m" }, "actions": [], "params": { "timeSize": 8, "timeUnit": "h", "count": { "value": 1, "comparator": "more than" }, "criteria": [ { "field": "bytes", "comparator": "more than", "value": 1 } ], "logView": { "logViewId": "log-view-reference-0", "type": "log-view-reference" }, "groupBy": [ "geo.dest" ], "outputIndex": ".alerts-observability.logs.alerts-default" } } ``` </details> 2. Start Kibana on 8.18. Verify that you cannot create the same rule and the rule created in step 1 starts failing. 3. Start Kibana on this PR and that you can create the same rule and the rule created in step 1 is working as expected. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 (cherry picked from commit 2a01722)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
Apr 8, 2025
…hreshold params (#217440) (#217526) # Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)](#217440) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Christos Nasikas","email":"christos.nasikas@elastic.co"},"sourceCommit":{"committedDate":"2025-04-08T13:58:26Z","message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","Team:ResponseOps","v9.0.0","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params","number":217440,"url":"https://github.com/elastic/kibana/pull/217440","mergeCommit":{"message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/217440","number":217440,"mergeCommit":{"message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
kibanamachine
added a commit
that referenced
this pull request
Apr 8, 2025
…threshold params (#217440) (#217525) # Backport This will backport the following commits from `main` to `8.18`: - [[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)](#217440) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Christos Nasikas","email":"christos.nasikas@elastic.co"},"sourceCommit":{"committedDate":"2025-04-08T13:58:26Z","message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","Team:ResponseOps","v9.0.0","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params","number":217440,"url":"https://github.com/elastic/kibana/pull/217440","mergeCommit":{"message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/217440","number":217440,"mergeCommit":{"message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
kibanamachine
added a commit
that referenced
this pull request
Apr 8, 2025
…hreshold params (#217440) (#217527) # Backport This will backport the following commits from `main` to `9.0`: - [[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)](#217440) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Christos Nasikas","email":"christos.nasikas@elastic.co"},"sourceCommit":{"committedDate":"2025-04-08T13:58:26Z","message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","Team:ResponseOps","v9.0.0","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params","number":217440,"url":"https://github.com/elastic/kibana/pull/217440","mergeCommit":{"message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/217440","number":217440,"mergeCommit":{"message":"[ResponseOps][Rules] Ignore unknowns in the schema of the log threshold params (#217440)\n\n## Summary\n\nA PR introduced into 8.18/9.0\n(#205507) changed the way we\nvalidate the log threshold rule type parameters. The validation happens\non rule params and changes a loose validation to a strict validation, so\nthose users who’ve inserted excess fields before 8.18/9.0 will see rules\nstarting to fail to run, their rule page failing to load and the API\nstarting to reject calls with excess fields.\n\nFixes: https://github.com/elastic/kibana/issues/217384\n\n## Testing instructions\n\n1. Start Kibana on 8.17 and create the following rule using the API. Let\nthe rule run.\n\n<details><summary>Rule</summary>\n\n```\n{\n \"name\": \"[QAF] Observability rule 3\",\n \"tags\": [\n \"metrics\",\n \"threshold\",\n \"qaf\"\n ],\n \"rule_type_id\": \"logs.alert.document.count\",\n \"consumer\": \"alerts\",\n \"schedule\": {\n \"interval\": \"1m\"\n },\n \"actions\": [],\n \"params\": {\n \"timeSize\": 8,\n \"timeUnit\": \"h\",\n \"count\": {\n \"value\": 1,\n \"comparator\": \"more than\"\n },\n \"criteria\": [\n {\n \"field\": \"bytes\",\n \"comparator\": \"more than\",\n \"value\": 1\n }\n ],\n \"logView\": {\n \"logViewId\": \"log-view-reference-0\",\n \"type\": \"log-view-reference\"\n },\n \"groupBy\": [\n \"geo.dest\"\n ],\n \"outputIndex\": \".alerts-observability.logs.alerts-default\"\n }\n}\n```\n\n</details> \n\n2. Start Kibana on 8.18. Verify that you cannot create the same rule and\nthe rule created in step 1 starts failing.\n3. Start Kibana on this PR and that you can create the same rule and the\nrule created in step 1 is working as expected.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"2a01722cfa42772b584e195eaebf4078e0cc5be2"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
|
This PR didn't make it into the latest BC. Updating the labels. ===== UPDATE: please ignore this comment, the PR did make it. |
|
From what I gather, it's part of the release based on the tags:
@mistic what filter did you use to label PRs as 9.0.1? |
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.
Summary
A PR introduced into 8.18/9.0 (#205507) changed the way we validate the log threshold rule type parameters. The validation happens on rule params and changes a loose validation to a strict validation, so those users who’ve inserted excess fields before 8.18/9.0 will see rules starting to fail to run, their rule page failing to load and the API starting to reject calls with excess fields.
Fixes: #217384
Testing instructions
Rule
Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.