Plans that fail to load give no hints to what went wrong

[micheal-w-wells]

"Retry or go back" doesn't give us much to go on. Could be an API issue (not callable, db constraint, etc) could be problem with React not liking the data coming from API, who knows.

We should pass on a more descriptive error to the user (and include something friendly like who to reach out to) if there is a problem. This will speed up troubleshooting issues that will come up.

[calebissharp]

@micheal-w-wells I'm not sure if it's a good idea to show stack traces in production. I did implement a change at some point that logs errors into the console when not in production. Really, we shouldn't have to rely on users to provide error logs to us, but instead use some kind of logging service. I don't know if the government has any preferences on what to use for that.

[micheal-w-wells]

While I agree no one needs to look at a big stack dump like jenkins gave us the other afternoon, in past experience there is operational benefit to error messages being a bit more informative. I'd say it should at least break things down to "error rendering page" (which wouldn't be logged on a server anyway) or "error communicating with API" as the user friendly messages, and underneath perhaps the more techy error (but not the whole stack dump). This gets even more valuable with increasing number of glued together systems. We'll have to tackle logging too at some point, you aren't wrong there.

[calebissharp]

Gotcha, I see what you mean. In this case, "error fetching plan" should be the only error that shows this page. If you look at the try-catch block, all that is deals with is 1) fetching the plan and 2) casting the plan against the schema. In a production environment, the schema cast should never fail once we iron out all the bugs in it. However, a fetch to the backend could definitely fail if the user loses internet connectivity or the API goes offline for some reason. For that reason, I don't think there's much more specificity we could supply in this specific error page. I'm ok with logging the actual thrown error in the console in production though (the same as what's configured for dev now).

There are other areas of the app where errors get thrown, which currently results in that "blank screen" issue that @LisaMoore1 has had a few times. With error boundaries, we could handle those kinds of errors differently.