Hello, >From the logs that you have provided, it seems like it is showing the error is origanting from the nginx server. Error 502's are most often served by a nginx process in each VM instance that sits in front of your application container. It has many uses including serving static resources according to handler rules defined in your app.yaml and serving 502s when the application container is unresponsive or otherwise crashes. Good places to look for your logs:
1. Application logs: If your application encounters errors on specific lines of code, it may still be logging other statements effectively so this can help determine where in your handler code the error occurs 2. stdout, stderr: If the runtime in the application container encounters errors, they may be found here. Accessing locked down libraries for instance or attempting to write to a file-system without write ability may generate errors visible here. 3. nginx.* logs: If the application container is entirely unresponsive (which could happen if busy, crashed, out of memory, etc.), nginx should still get the requests and generate appropriate logs. These log entries may indicate what the nginx process sent to the application container and what it received (or likely failed to receive) 4. Cloud HTTP Load Balancer request logs: If the entire instance is unresponsive including its nginx process, the load balancer may respond with failure codes to ensure client requests don't hang forever. This may happen if the application occupies all of the VM's resources like CPU or memory You can check HTTP Load Balancer logs <https://cloud.google.com/load-balancing/docs/https/https-logging-monitoring#viewing_stackdriver_monitoring_dashboards> inside Stackdriver for App Engine Flex and try to identify the status details <https://cloud.google.com/load-balancing/docs/https/https-logging-monitoring#what_is_logged>that shows up in your stackdriver logs.I have found some helpful threads 1 <https://stackoverflow.com/questions/43818967/502-bad-gateway-error-for-my-server-running-with-node-js-on-nginx-proxy>, 2 <https://stackoverflow.com/questions/41305122/some-502-errors-in-gcp-http-load-balancing> and 3 <https://stackoverflow.com/questions/38012797/google-app-engine-502-bad-gateway-with-nodejs> which provides useful information regarding your issue. Also, just for completeness and clarity, the error you might see could mean that the nginx proxy on that specific instance of your backend service fails to contact the webserver (aka your app) in that instance (it is all localized to a specific instance). Normally these often occur due to nginx's health checks failing, but this can also just happen when nginx does its normal job of proxying incoming requests to your application. Essentially, the connection between nginx and your application closes due to your application not responding to it, or your application completely stops listening to nginx (it listens on port 8080 <https://cloud.google.com/appengine/docs/flexible/nodejs/runtime#application_startup> as seen in the error). Therefore, the issue all comes down to your application code and the Node.js runtime. Node.js is a single threaded runtime, this means that your code must be properly coded to take full advantage of Node.js's event loop <https://blog.risingstack.com/node-hero-async-programming-in-node-js/> in order to be asynchronous. By having async code, you are allowing concurrent requests to be executed, which in turn allows your application to always listen and respond to nginx. Once your application becomes asynchronous, it is able to properly live and scale in the cloud. Note that you should always perform exponential backoff-retry <https://cloud.google.com/storage/docs/exponential-backoff> on the client-side (aka you proxy service) in the case that your backend service becomes too busy and times out. This way, even if you see 5xx responses, your client should always eventually succeed (once your backend has recovered). If you have tested turning the nginx health checks off <https://cloud.google.com/appengine/docs/flexible/nodejs/configuring-your-app-with-app-yaml#health_checks> and you still see these 502 errors, then I highly suggest you report this in the Public Issue Tracker <https://cloud.google.com/support/docs/issue-trackers>. If the issue is resolved when the health checks are off, then you may be able to reduce the thresholds and intervals of the checks to allow your instances more time to respond to nginx. - If you do open an issue report, it is recommended to provide your project ID, the type of health checks you are using (legacy or updated), and a stacktrace of the error you are seeing. Regarding the seconds inquiry, you might find these threads 1 <https://github.com/expressjs/session/issues/556>,2 <https://stackoverflow.com/questions/44882535/warning-connect-session-memorystore-is-not-designed-for-a-production-environm> to be useful as it addresses the 'Warning' message that you have been receiving about Memorystore. Please note Google Group mainly focuses on general discussions about Google Cloud Products and services. If you need further assistance regarding this ongoing issue you can create an issue as I have mentioned earlier on our Public Issue Tracker <https://cloud.google.com/support/docs/issue-trackers> thread and additionally post the issue on Stackoverflow <https://stackoverflow.com/> to receive further assistance from the community. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/66aed18c-bb12-4274-88c6-707ca69cac67%40googlegroups.com.
