Server Responding With 502 Status Code

[plang-psm]

Dependency

• 401 Status Code at Launch #1320 has been resolved.

Overview

A Server not responding alert is sometimes displayed to users after they select the PROJECTS tab from the navbar. The error is triggered after the frontend requests the /api/projects/ endpoint from the server. The server responds with a 502 status code.

See screenshot of error

Action Items

• Check Epic: Tracking time sensitive errors #1323 to see if any of the completed issues resolved this one. If so, close this issue.
• Investigate the situation further and communicate findings with the team
• Figure out who we need to communicate with to access AWS deployment information
• Determine how to approach fixing the issue

Phillip Notes

When clicking the ADMIN tab is selected

• Why is events being triggered via login?

When clicking the PROJECTS tab while the Dashboard is loading

• Why does /projects output 502 status codes but work when refreshed?
• Why is recurringEvents being triggered when you click Projects tab?

• 2nd time running the error.

Matt Notes

• The frontend is deployed with an Amazon Elastic Container Service
• Confusing how the production server only sometimes responds to /api/projects GET requests with the 502.
• Since error never occurs in our local dev environment, problem may need to be addressed on AWS

Instructions

Login to dev.vrms.io as an admin user and visit the Projects List page, the server will sometimes respond with a 502 status code for the GET requests our frontend makes to the /api/projects/ endpoint which results in the frontend /projects route failing to render the ProjectList component.

Resources

• AWS ECS logs for vrms-backend-prod service ( login using credentials in VRMS 1Password vault )
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html

[MattPereira]

You may have some trouble recreating this error on dev.vrms.io but it does sometimes happen there especially if you access it in incgonito mode

The errors seem to occur much more frequently in production at vrms.io

Both dev.vrms.io and vrms.io are currently deployed from the same commit

[JackHaeg]

Per @spiteless, next steps would be to incorporate logging to figure out the issue.