Zappa: Random 'NoneType' object is not callable

I only have the zappa examples in my virtual env: https://github.com/Miserlou/Zappa/tree/master/example

The biggest part of the env is importing scipy and sklearn and these two together make up for about 60M. I need them in order to deploy my machine learning model.

Why is slim_handler = true not working? Unless I’m missing something, I don’t think there’s any chance I can get my zip under 50M. Any other idea for using zappa in this scenario?

I’m having the same problem. I first get it to work, then I add the dependencies sklearn numpy scipy and setting "slim_handler": true. After that I get: 'NoneType' object is not callable

I too turned off slim_handler, and the issue hasn’t happened again.

I stopped having this issue when I stopped using the slim_handler= true option. Not sure if this is it but I never experienced this issue for about a month until I started using the slim_handler, after that It happened about every day.

It happened again today. Doing the above, I got the following traceback:

1492967445091] 'NoneType' object is not callable
[1492967445091] Traceback (most recent call last):
[1492967445091] File "/var/task/handler.py", line 450, in handler
[1492967445091] response = Response.from_app(self.wsgi_app, environ)
[1492967445091] File "/tmp/pip-build-c5E7tR/Werkzeug/werkzeug/wrappers.py", line 903, in from_app

Well I came across the issue lately and took time to investigate the problem. The issue is that lambda is timing out, at least for my case and I believe for many cases here too. Go over the logs in cloudwatch because unlike zappa tail logs, cloudwatch separate logs into logs from each container created by lambda as streams. I observed when a faulty container (one returning NoneType) diverged from the normal one. This is what happens.

So once a request comes in and all the fired up containers are in use, a new container is created and during initialization, because we’re downloading files from s3 to /tmp and also due to sometimes lagged connectivity + vpc/db initilializations, lambda doesn’t always finish setting up within the default 30s lambda time_out set by zappa. Hence, the container times out and starts receiving request pre-maturely when in reality the modules have not all been imported. Hence the NoneType error. For every NoneType eror that I saw in cloudwatch, there was an import issue beforehand which confirms this. Therefore when new requests hit that container periodically, we see the NoneType. But when new request hit other containers without this issue, it works. And that explains for the periodic NoneType Error we get.

Hence these are what you can do.

If you can reduce the size of your code/dependencies please do so for two reasons 1) As others have mentioned above, if you can get your code + dependencies to meet the 250M unzipped / 50M zipped limit, then you can set the slim_lambda==false flag or remove it entirely as the default is false.

2)If you cannot get it to meet the aws limit, the little code you remove will help because now you have reduced the files + time it has to download from s3 and maybe you never experience any time out again.

Now if you can’t get your code base reduced to to the 250M unzipped / 50M zipped limit, maybe you’re in case (2) above or can’t even reduce anything at all, increase timeout_seconds from 30s to something like 60s.. The worst that could happen by increasing timeout_seconds is that you may hit api gateway timeout once because of the 30s api gateway limit, and after that by the next request your lambda must have already been set up and ready to serve requests. Therefore you’ll not come across the NoneType object is not callable object error any longer.

To everyone else here that might have some issues - by commenting one line at a time and uploading again and again, I’ve realized that an import statement in the top of the app.py failed to execute, failed silently in zappa, and then raised the odd NoneType object is not callable exception. Surrounding the failing import statement with:

try:
    import something from failing_import
except Exception as e:
    print("Failure with {}".format(e))

I was able to find the actual issue in the dependent package, solve it, and upload my zappa function with no issues this time.

I’m not sure why the import exception was not visible by zappa in the first place. BTW, the actual issue was in another package installing the typing module while running in python 3.7…For some reason it got broken only on AWS.

Would it be possible and safe to ignore .pyc files from source project directory? Deleting .pyc files from my source project and zappa update helps everytime for me to solve 'NoneType' object is not callable. I am using Python3.6 runtime for lambdas, but everytime I accidentaly run the flask app locally with Python2, the pyc files are created and the problem emerges in AWS after zappa update

I found a cause for my problem with NoneType is not callable. I had pyc files between some of my source files that became part of zip. Deleting them and running zappa update solved my problem. I found error like this https://teamtreehouse.com/community/importerror-bad-magic-number-in-time-bx03xf3rn and it lead me to the pyc files.

Someone who is looking for a solution this might help.

1. If you are deploying from a Mac consider doing it from a docker container (so it can get the linux dependencies)
2. You can also be missing some dependencies which was not required in your Mac but required in Linux. In my case I had to add pycrypto to my requirements file.

Hope this helps.

In my case, the issue was caused by:

• slim_hander: true
• conservative memory and timeout settings

Solution: Increase memory_size and/or timeout_seconds.

These are the steps I took:

• Created a new venv with zappa and flask (nothing else)
• Deployed with memory_size: 128, timeout_seconds: 20, and slim_handler: false (worked as expected)
• Added some large dependencies (~60mb)
• Deployed with slim_handler: true. Received the “NoneType…” error.
• Increased memory to 512mb. Deployed, and works as expected.

Thanks to @eexwhyzee for his comment prompting me in the right direction. Also in general, it’s a good idea to check metrics/logs in the lambda console or cloudwatch. This revealed that memory was maxing out.

You’re also going to want to delete __pycache__ directories

I had the same problem. Just 'NoneType' object is not callable and nothing else in the logs.

“Refreshing” my virtualenv solved the problem:

pipenv --rm
rm Pipfile.lock
pipenv install
pipenv install --dev

I decided to do that because I noticed that Zappa was packaging some modules that I clearly uninstalled before. So may be it’s pipenv that caused the problem.

(this issue is the first on google for the NoneType exception) In my case the issue was caused by using a remote config (on s3) and one of the values being a number. This resulted in “Environment variable keys must be non-unicode” error, which I saw in the zappa tail.

Finally found the cause of my issue. A build script that ran before zappa included a sed command that did not flush the output buffer, which sometimes truncated my app.py file. If you are experiencing the variant of this issue that goes away when you re-deploy, check your build scripts for this sort of race condition.

@Miserlou Any update on this ? I started facing this issue after using the slim_handler= true option.