uvirorn.workers.UvicornWorker fails with certain ASGI middleware

Description

Certain middleware is fails, either when launcing Uvicornworker, or when calling the ASGI handler. A concrete case is the SentryAsgiMiddleware. See https://github.com/getsentry/sentry-python/issues/947 for info. Not sure if the problem is in Uvicorn or Sentry.

To reproduce

Install the Sentry lib in a ASGI application, run with gunicorn/uviworker

from sentry_sdk.integrations.asgi import SentryAsgiMiddleware
app = SentryAsgiMiddleware(app)

and

gunicorn api:app -w 1 -k uvicorn.workers.UvicornWorker

Expected behavior

Application launches and runs

Actual behavior

As set up above, the following error is produced when launcing gunicorn:

File "/usr/lib/python3.7/inspect.py", line 2208, in _signature_from_callable
    raise TypeError('{!r} is not a callable object'.format(obj))

If I forcefully expose either a asgi2 or asgi3 interface from the middleware, using either the _run_asgi2() or _run_asgi3() methods on the middleware object, the servers starts up, but then fails when handling a request, with e.g.:

TypeError: _run_asgi3() missing 2 required positional arguments: 'receive' and 'send'

Apparently, the introspection of the callable fails to recognize method objects.

Additional context

Using the uvicorn webserver it is possible to specify asgi2/3 interface using a commandline argument, and thus override the detection mechanism, which seems to be failing on this particular middleware. Using the Uvicorn worker this appears to be not possible.

again, see issue here. See https://github.com/getsentry/sentry-python/issues/947 for info.

[kristjanvalur]

Hm, being an old school Python guy, I probably would have opted for just calling the object, without an argument, and if that worked, assume that it was a factory. Otherwise, handle the exception and assume it was an app instance. In my experience type inspection only ever caused grief.

[florimondmanca]

To be clear AFAICT the bug here is not related to determining ASGI 2 vs ASGI 3, but related to “app instances” vs “app factories”. The latter case was introduced recently via a --factory flag, and the code at fault was meant to try and detect when a factory is passed without the flag (so we don’t just crash with an odd “app expected 0 arguments but got 3” error message).