Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ResponseOps][Discuss] prevent errors like removed references in the future #153892

Open
pmuellr opened this issue Mar 28, 2023 · 2 comments
Open
Labels
Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Mar 28, 2023

We recently found an issue with one of our APIs which ended up in a data loss situation - #152961

This issue is to discuss ways of catching issues with this earlier. Anything goes!

This is a fairly complex issue, as it involved specific rule types, which we don't test with a lot, and APIs run against those rules. After the API ran, the rule SO was damaged and needs to be deleted (or at least we don't have an easy fix at the moment).

On the face of it, the exhaustive test of this would require testing all our rule types, with different types of parameters (so more than one rule of the same type), using all of our APIs that mutate the rule SO against the rule, and then make sure it's still running.

Which is a LOT of work.

In this particular case, the issue was with "references" (saved object references saved as part of the rule params) - so at least for the "references" concern, we can narrow the rule types to two - elasticsearch query and tracking containment.

Perhaps we can just start by augmenting some existing tests. For instance, in the tests here - tests/alerting/update_api_key.ts, we could:

  • use real rule types (for instance, elasticsearch query) instead of the test-specific rule types, at least for some of the tests
  • have the tests ALSO test the remaining fields in the rule - they should be unchanged since before the API was called; note, not sure if the rule APIs give us EVERYTHING we want - we may want to get the docs from ES instead.
@pmuellr pmuellr added the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label Mar 28, 2023
@elasticmachine
Copy link
Contributor

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

@XavierM
Copy link
Contributor

XavierM commented Jun 14, 2023

We will review @JiaweiWu 's PR when we are done with http versioning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests

3 participants