502 error: "Process exited unexpectedly before completing request"
In Custom Container runtimes, the HTTP server process terminates before Function Compute receives a complete response. Either the HTTP server closes the connection prematurely, or the process crashes due to an unhandled exception or explicit exit call.
Check function logs first to determine which cause applies, then follow the corresponding fix.
Cause 1: HTTP server closed the connection
Function Compute maintains a persistent keep-alive connection to the HTTP server in a Custom Container runtime. If the server closes this connection, Function Compute loses its communication channel to the container.
This typically happens when:
-
Keep-alive is not enabled on the HTTP server.
-
The HTTP server closes idle connections after a timeout shorter than 15 minutes.
-
A read/write operation times out or returns an error, causing the server to drop the connection.
How Function Compute handles connection failures:
| Request type | HTTP methods | Behavior on connection failure |
|---|---|---|
| Idempotent | GET, HEAD, OPTIONS, TRACE | Function Compute retries the request automatically |
| Non-idempotent | POST, PATCH | Function Compute returns a 502 error without retrying |
Because non-idempotent requests are not retried, proper keep-alive configuration prevents 502 errors on POST and PATCH requests.
Fix: configure keep-alive and idle timeout
Apply both settings on the HTTP server running inside the custom container:
-
Enable keep-alive mode on the HTTP server.
-
Disable idle timeout, or set it to more than 15 minutes. Function Compute may reuse connections after long idle periods. If the server closes the connection before Function Compute sends the next request, the connection is lost.
The exact configuration depends on the HTTP server framework. The following examples cover common frameworks.
Go (GoFrame)
s := g.Server()
// Disable idle timeout to prevent the server from closing keep-alive connections
s.SetIdleTimeout(0)
// ReadTimeout defaults to 60s; adjust if needed for long-running requests
Python (Uvicorn)
# Set --timeout-keep-alive to a value greater than 900 seconds (15 minutes)
uvicorn app:app --host 0.0.0.0 --port 9000 --timeout-keep-alive 920
Node.js (Express / HTTP)
const server = app.listen(9000, '0.0.0.0');
// Set keepAliveTimeout to a value greater than 900000 ms (15 minutes)
server.keepAliveTimeout = 920000;
server.headersTimeout = 940000;
Verify the fix
After deploying the updated configuration, send a few requests with pauses of several minutes between them to simulate sparse invocations. Confirm that no EOF or connection reset by peer errors appear in the function logs.
Cause 2: process crashed unexpectedly
The container process exited before completing the request. This is a code-level issue, not a connection configuration issue.
Common causes:
-
The code calls an explicit exit operation (for example,
os.Exit()in Go,sys.exit()in Python, orprocess.exit()in Node.js). -
An uncaught exception terminates the process.
Fix: remove exit calls and add top-level exception handling
-
Check for explicit exit calls. Search the codebase for exit operations (
exit,os.Exit,sys.exit,process.exit). Remove any that run during request handling, or replace them with error responses. -
Add top-level exception handling. Wrap the request handler in a try-catch block so that uncaught exceptions return an error response instead of crashing the process.
Python (Flask)
@app.errorhandler(Exception) def handle_exception(e): # Log the error and return a 500 response instead of crashing app.logger.error(f"Unhandled exception: {e}", exc_info=True) return {"error": "Internal server error"}, 500Node.js
// Catch unhandled exceptions to prevent the process from exiting process.on('uncaughtException', (err) => { console.error('Uncaught exception:', err); }); process.on('unhandledRejection', (reason) => { console.error('Unhandled rejection:', reason); });
Verify the fix
After deploying the fix, invoke the function with the same input that previously triggered the 502 error. Confirm that the function returns a valid response (even if it is an error response) instead of a 502.
Diagnostic checklist
If the cause is unclear, work through this checklist:
-
Check function logs. Look for
EOF,connection reset by peer, or exception stack traces. -
Check whether the error correlates with idle time. If 502 errors appear after periods of no traffic (sparse invocations), the HTTP server is likely closing idle connections. See Cause 1.
-
Check whether the error is consistent or intermittent.
-
Intermittent errors on POST/PATCH requests suggest a keep-alive or timeout misconfiguration.
-
Consistent errors on every request suggest a process crash.
-