Closed drewbo closed 2 months ago
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:
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:
v0/organizations
)req.logout
)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 eventsreq.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.
We've seen sporadic application crashes originating from the session authentication code
Acceptance Criteria