Prevent the application from crashing on unhandled session auth errors

[drewbo]

We've seen sporadic application crashes originating from the session authentication code

Acceptance Criteria

• [x] Session authentication code doesn't crash the application
• [x] Session authentication code returns one response only, in all branches
• [x] Application fetch code can handle redirect responses from our API

[drewbo]

More detail: we've seen occurrences of Process has crashed with type: "web" in our production logs. These are infrequent and don't cause application downtime because we run multiple instances but present a potential issue at scale and likely a bad customer experience. The log timeline around these occurrences is slightly unusual but looks roughly like this:

• Unhandled 500 error
• Process exits with exit code 0
• 5 seconds later, another instance crashes with the above error log.

I'm not sure why the logs appear that way but it still seems prudent to prevent the underlying error. This error generally seems to come from the session authentication middleware. We've found two previous errors in a specific branch of this code but it is still erroring with Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client. An example of why this is likely happening:

• A previously logged in user attempts to hit an endpoint requiring auth (example v0/organizations)
• The session auth middleware correctly sees that the authentication is old and attempts a logout (req.logout)
• Because there is no return in the first portion of the if block, we still call the next function and attempt to reach the controller without a valid user. This will error, return 500 to the user, and appear in our audit events
• The req.logout callback fires after this, and attempts to do res.redirect after we've already exited the "request-response cycle". This results in a second error which appears in our application logs (Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client) and crashes the process.

@apburnes found that even preventing this errant flow in the nested if block will still result in an error in the surrounding if block, which also doesn't have a return statement which causes the forbidden response to fire for expired authentication, and another instance of trying to double up on sending res (causing a header error again).

Furthermore, preventing this second error still causes issues because our internal fetch implementation doesn't properly handle the final redirect response.