🐛 Authorization error should not cause a page to crash entirely

[tristan-orourke]

We are making queries on the admin side which include a message about unauthorization errors, but most of the data is actually present! For example, in #6149, a pool field deep in the query was null, but we had most of the data we needed. And thanks to Typescript, we're checking for nulls everywhere we need to! It would be nicer to show a toast error, but also render as much of the page as possible.

[petertgiles]

Overall, I 100% agree that if we can return a meaningful amount of information to the user without crashing, that would better. However, it does make error handling much more difficult. I can imagine scenarios where we would need to know if something is actually missing or if it's there but can't be delivered. I guess we'll need to figure out if we can get the API to respond with both an error and data properties? But it does make error handling more complex.

It seems like Lighthouse might be able to do this? https://lighthouse-php.com/6/digging-deeper/error-handling.html#partial-errors

[esizer]

We are using partial errors in the messy CreateApplication page ( #4469 ) when a user has already applied to a pool. What happens is we return the error and the PoolCandidate so we can redirect the user to the the existing application. I'm not sure how this works with authorization though 🤔

You are correct though, this does make error handling much more complex on both the back and frontend. We would need to parse the errors return to check what type of error it is and handle it appropriately.

[tristan-orourke]

I guess we'll need to figure out if we can get the API to respond with both an error and data properties

I'm pretty sure the API already does this if an authorization error is caused by a directive nested deeper in the query.

[tristan-orourke]

But now that I'm looking for an example, it seems like the majority of the time, if the query has an authorization error, it'll be at the top level. And the exceptions would likely only happen on an Admin page where we're querying for something we shouldn't - and maybe we want to highlight the error anyway so we can fix the bug?

[petertgiles]

Yeah, there's something to be said for quickly surfacing legitimate problems that are not user errors. How do we differentiate user errors from real bugs?

[brindasasi]

I'm always in favor of not providing the opportunity to make the user error. For ex. If the user doesn't have permission to view the candidate details hide that link. Render the page with only allowed actions for that user.

[tristan-orourke]

Seems like we're in favour of letting errors surface issues early, rather than trying to work around them silently. And this kind of error was a lot more niche than I realized anyway. I'm closing this discussion.