Container Image runs fine with AWS Lambda Runtime Interface Emulator, but 502 on zappa deploy

Context

I followed the steps here to create a container image, upload it to ECR, and run zappa deploy -d. All routes work perfectly when I test out the image with the AWS Runtime Interface Emulator, i.e, curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"path": "/", "httpMethod": "GET", "requestContext": {}, "body": null}', but zappa deploy -d throws me a 502 error. I’ve run zappa tail, but all I see there is [1659730496257] 'NoneType' object is not callable.

Unfortunately I’m not cleared by my company to release more than the settings.json file here, but happy to share more details privately.

I have a few questions:

1. How is it possible that the image works when being tested on the runtime interface emulator, but fails during deployment? I’ve rewritten the settings file and made sure that slim_handler is set to false as well.
2. Are there any suggestions on where to embed print statements in the handler.py to make zappa tail more informative during debugging?
3. Given that I’m deploying this as a docker image, I am not using a venv, and invoking zappa from my project’s conda environment. Could this be the root of any issues?

Expected Behavior

zappa deploy -d executes successfully and returns the API endpoint.

Actual Behavior

1. NoneType object is not callable. Same message replicated in zappa tail. But the same image works when tested with the AWS local Runtime Interface Emulator

Your Environment

• Zappa version used: 0.55.0
• Operating System and Python version: macOS 12.4 Monterrey, Python 3.9
• The output of pip freeze: Running everything in docker, so shouldn’t be an issue
• Link to your project (optional):
• Your zappa_settings.json: { “lambda_docker_flask”: { “app_function”: “server.app”, “project_name”: “app”, “lambda_description”: “Zappa + Docker + Flask” } }

[padmanabhankrishnamurthy]

Good to know!

For anyone browsing this thread looking for ideas about the 504 error - in my case, my app.py script was importing a ton of heavy libraries. Just importing the libraries and instantiating a few global objects was taking ~60s, by which time a timeout error was thrown. Moving the imports and instantiations to the route instead of keeping them global, and also using the task async decorator solved the issue for me.

[padmanabhankrishnamurthy]

Update for anyone facing similar issues: FIXED

I try/except’ed every import statement in my app and printed out all failures. Turns out all my issues were caused because of module import errors. After resolving those import paths, my app loads successfully. Not sure why this had to be done since Dockerizing the app shouldn’t have allowed import errors to exist (or am I mistaken?).

I’m now facing 504 timeout errors, but that’s a story for another day.