TypeError: __call__() missing 1 required positional argument: 'start_response'
See original GitHub issueHello. I have a similar problem like here.
My development environment is working fine.
Python 3.8, Win 10
Django 3.0.2, Gunicorn Version 20.0.4, Uvicorn Version: 0.11.1:
uvicorn config.asgi:application
But on production environment I use docker.
Docker image: python:3.8-alpine
Django 3.0.2, Gunicorn Version 20.0.4, Uvicorn Version: 0.11.1
CMD ["gunicorn", "-b", "0.0.0.0:8010", "--workers", "5", "-k", "uvicorn.workers.UvicornWorker", "config.asgi:application"]
The application starts, but when you request any page, the server gives 500:
gate | [2020-01-13 13:47:51 +0000] [9] [ERROR] Exception in ASGI application gate | Traceback (most recent call last): gate | File “/usr/local/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py”, line 385, in run_asgi gate | result = await app(self.scope, self.receive, self.send) gate | File “/usr/local/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py”, line 45, in call gate | return await self.app(scope, receive, send) gate | File “/usr/local/lib/python3.8/site-packages/uvicorn/middleware/asgi2.py”, line 6, in call gate | instance = self.app(scope) gate | TypeError: call() missing 1 required positional argument: ‘start_response’
I tried to dig deeper, but it’s hard for me.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:4
- Comments:6 (1 by maintainers)
@ayois, No, I just changed the image. IMHO, the fact is that Alpine Images come with another implementation of the standard LIBC library - MUSL, and it is likely that it leads to some implicit behavior in Python modules, including Uvloop.
I also noticed problems with the launch of this environment on Python3.9. The choice of the docker image of Python3.8 or Python3.7 based on the debian will be more reliable.
I updated the base image to python:3.8-slim-buster and python:3.9-slim-buster and ran into the same error. I took a closer inspection afterwards to debug, and it turns out the issue was the WhiteNoise wrapper I used on the application in the asgi.py file. The issue is now resolved. Thanks for the help pinpointing the issue!