Hey Deepak,
My apologies as we seem to have missed this post. Nevertheless, if you believe some behavior to be an error with the platform, the best place to report it for App Engine is the
App Engine public issue tracker. In doing so, you can submit screenshot, logs, reproductions, etc. with privacy so that we can help identify the root cause and improve the platform accordingly should the source prove to be platform-related.
In the issue report, please include the following:
- Runtime used (runtime: custom, vm: true or env: flex). These factors affect the serving infrastructure in the backend and knowing this greatly helps us narrow down a possible point of error.
- Specific time frames. Having specific timestamps of the first recorded occurrence and last recorded occurrence of a given error is very helpful. Knowing this range can help us correlate your report with issues we might have filed internally accelerating our investigation.
- SDK versions. Knowing the code base can greatly trim down the research required to know where an error might be occurring if it is in fact with the platform.
- Relevant logs. 502s 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:
- 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
- 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 withour write ability may generate errors visible here.
- 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)
- Cloud HTTP Load Balancer request logs. If the entire instance is unreponsive 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
I hope the above information is helpful to you and others in the community attempting to troubleshoot 502-3 errors. After reporting a new issue on the tracker, feel free to post a link to it here so that others can follow through.
Regards,
Nicholas