Open
Description
This is a request spurred by recent issues (#13130 and coder/coder#13723). Decided to spin this off into a separate issue instead of piling more stuff on top of the latest issue.
Problem
In the past two months, we have had two breaking issues slip through all of our error handling and lead to the entire UI app blowing up. This issue outlines steps for improving the dashboard's general reliability, and making it much harder for these problems to happen again.
Action items
- Turn on TypeScript's
noUncheckedIndexedAccesscompiler setting- This setting can present a bit of a difficulty curve depending on how you write your JS/TS, but it basically ensures that we will never accidentally access a property from a null/undefined value again (unless we use type assertions to silence type warnings)
- I don't think we'll need to change too much of our existing code to make the compiler happy with this setting, but I'm sure there's at least a few lines we'd have to change
- This setting 100% would've caught Trying to download logs for failed workspace makes entire page for that workspace unusable coder#13723.
- Investigate why our current top-level error boundary is letting errors slip through as uncaught errors
- We have an error boundary in place that is supposed to catch any render errors, and display a fallback UI. It's wrapped around our entire application, but it hasn't always been triggering.
- Add an additional error boundary around the main content of the app
- Even if the top-level error boundary would always trigger when needed, there's still the matter that if an error happens in one part of the app, the entire app unloads for the fallback UI
- I suggest adding at least one more error boundary around the main content (everything below the nav bar, basically). This would make it so that even if an error happens, the navigation will still likely be enabled. The top-level error boundary should be for completely unprecedented, unrecoverable errors.