This PR simplifies and organizes the failure states for historical detectors. Currently, all failures are grouped into the Unexpected failure state, except for the No data state. Since there are other handled failures (e.g., "Not enough data to initialize"), these should also not be ignored, and we should provide some useful information to the user. However, creating more states similar to No data state introduces a lot of extra code, and makes it difficult to maintain compatibility on the frontend with all of the possible backend/ES failures.
To simplify this, we group the failures into (1) Unexpected failure and (2) Failed states by parsing out the backend error message. If the message is a stack trace: we consider it unexpected, with no readable error message. If the message is anything else, we consider it handled, and propagate that error message to the frontend via a callout on the historical detector details page.
Details & examples on the 4 possible types of error messages that need to be handled can be found in the function here and the corresponding unit test here.
Added unit tests & confirmed all are passing.
Screenshots:
Failed state with propagated ES error message:
Unexpected failure state:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Issue #, if available:
Description of changes:
This PR simplifies and organizes the failure states for historical detectors. Currently, all failures are grouped into the
Unexpected failurestate, except for theNo datastate. Since there are other handled failures (e.g., "Not enough data to initialize"), these should also not be ignored, and we should provide some useful information to the user. However, creating more states similar toNo datastate introduces a lot of extra code, and makes it difficult to maintain compatibility on the frontend with all of the possible backend/ES failures.To simplify this, we group the failures into (1)
Unexpected failureand (2)Failedstates by parsing out the backend error message. If the message is a stack trace: we consider it unexpected, with no readable error message. If the message is anything else, we consider it handled, and propagate that error message to the frontend via a callout on the historical detector details page.Details & examples on the 4 possible types of error messages that need to be handled can be found in the function here and the corresponding unit test here.
Added unit tests & confirmed all are passing.
Screenshots:
Failed state with propagated ES error message:
Unexpected failure state:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.