Set result status code when returning a non-200 response

[rocketnova]

Ticket

Resolves #406

Changes

• Explicitly set the response status code if there is an error

Context

Right now, if we return an error page, we are still sending a 200 response code. We should be setting the appropriate HTTP response code.

Note: It turns out that writing a unit test for HTTP responses in Next.js is non-trivial, so I broke that out into a separate ticket so we can get the functionality merged now: #411 Here are a few leads:

• Using cypress: https://blog.logrocket.com/testing-and-error-handling-patterns-in-next-js/
• Manually: Are there official samples for testing API routes with Jest vercel/next.js#15166
• Using next-test-api-route-handler

Testing

1. Checkout this branch
2. Run yarn dev
3. Open the browser Network pane
4. Make a request without passing a unique header
5. Verify that the Claim Status Tracker displays a 500 error and also returns HTTP error 500

[kalvinwang]

Code lgtm! After this is merged and deployed to prod, I think it's going to break the availability test because 500s will start being returned because the unique number in the test is still for prod API gateway (unless you changed it yesterday) even though it's now connected to preprod UAT. Not sure what a good general process is for updating that when deploying, any ideas?

[kalvinwang]

Suggested change

	// If there is an errorCode, set the response statusCode to match.
	// If there is an errorCode from the API gateway, set our app's response statusCode to match.

[rocketnova]

@kalvinwang I'm not including this suggestion because the error code is set for issues that are not limited to errors from the API gateway. It's any application level error (e.g. env vars missing, catching a thrown error, etc).

[kalvinwang]

ooh, got it, thanks!

[rocketnova]

After this is merged and deployed to prod, I think it's going to break the availability test because 500s will start being returned because the unique number in the test is still for prod API gateway (unless you changed it yesterday) even though it's now connected to preprod UAT. Not sure what a good general process is for updating that when deploying, any ideas?

@kalvinwang I think this is an example of how the avalibility tests are brittle, but without an equivalent healthcheck endpoint we can call on the API gateway, I'm not sure there is a better alternative. We have a section of the Foundation doc called Connecting to different API gateway environments. Maybe we should just make that a more robust checklist and include updating the availability tests in that checklist. Thoughts?