None of them was strictly caused by a bug in Security, but by some other process adding a big number of fields to some of the customer indices accidentally. This causes our indexFields request to respond with a number of fields that the Alerts page can't handle, resulting in a "Maximum call stack size exceeded" error.
The problem is usually solved by another team, but the page that crashes with the full-screen error is the Security Alerts page. We should improve the Alerts page UX to prevent the app to crash in these situations, making the application more resilient and showing some meaningful message to the customer when this happens.
Improvements
Re-check all field processing functions' performance, we should be able to do everything with O(n) runtime complexity.
Add a limit to the number of fields we can process, if the limit is hit:
Slash the fields array to that limit.
Show a warning message to the user acknowledging the page may not work properly, and pointing where to look to fix the issue (would be great if we could identify the problematic category / indexPatern)
Describe the feature:
Lately, we are receiving a number of SDHs related to "Maximum call stack size exceeded" on the Security Alerts page:
None of them was strictly caused by a bug in Security, but by some other process adding a big number of fields to some of the customer indices accidentally. This causes our
indexFields
request to respond with a number of fields that the Alerts page can't handle, resulting in a "Maximum call stack size exceeded" error.The problem is usually solved by another team, but the page that crashes with the full-screen error is the Security Alerts page. We should improve the Alerts page UX to prevent the app to crash in these situations, making the application more resilient and showing some meaningful message to the customer when this happens.
Improvements