lifespan protocol not implemented?

[trim21]

Offical spec https://asgi.readthedocs.io/en/latest/specs/lifespan.html

I'm using uvicorn and fastapi. I originally using encode/sentry-asgi and these days I found that there is a AsgiMiddleware in sentry-sdk. So i try to start using sentry_sdk.integrations.asgi.SentryAsgiMiddleware But I got

INFO: ASGI 'lifespan' protocol appears unsupported.

I got this error in asyncio debug mode:

WARNING: Executing <Task pending coro=<Server.serve() running at C:\Users\Trim21\.venv\www\lib\site-packages\uvicorn\main.py:322> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x0000019878C3C468>()] created at C:\Users\Trim21\AppData\Local\Programs\Python\Python37\lib\asyncio\base_events.py:391> cb=[_run_until_complete_cb() at C:\Users\Trim21\AppData\Local\Programs\Python\Python37\lib\asyncio\base_events.py:153] created at C:\Users\Trim21\AppData\Local\Programs\Python\Python37\lib\asyncio\base_events.py:558> took 1.265 seconds
ERROR: Exception in 'lifespan' protocol
Traceback (most recent call last):
  File "C:\Users\Trim21\.venv\www\lib\site-packages\uvicorn\lifespan\on.py", line 44, in main
    await app(scope, self.receive, self.send)
  File "C:\Users\Trim21\.venv\www\lib\site-packages\starlette\applications.py", line 133, in __call__
    await self.error_middleware(scope, receive, send)
  File "C:\Users\Trim21\.venv\www\lib\site-packages\starlette\middleware\errors.py", line 142, in __call__
    await self.app(scope, receive, send)
  File "C:\Users\Trim21\.venv\www\lib\site-packages\starlette\middleware\base.py", line 21, in __call__
    await self.app(scope, receive, send)
  File "C:\Users\Trim21\.venv\www\lib\site-packages\starlette\middleware\base.py", line 21, in __call__
    await self.app(scope, receive, send)
  File ".\app\middlewares\log.py", line 12, in __call__
    await self.app(scope, receive, send)
  File "C:\Users\Trim21\.venv\www\lib\site-packages\sentry_sdk\integrations\asgi.py", line 71, in _run_app
    span = Span.continue_from_headers(dict(scope["headers"]))
KeyError: 'headers'

It's not a http event so there is no headers key in scope

env:

uvicorn version: 0.8.6
fastapi version: 0.38.1
python version: 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)]
sentry-sdk version: 0.12.1

[untitaker]

hmm cc @tomchristie.

The middleware in this SDK is a fork of encode/sentry-asgi, with the intent to deprecate sentry-asgi (afaik @tomchristie agreed to this plan). But it seems that both are now maintained?

I would like to keep the one inside the SDK, because I can then build integrations for Channels and other web frameworks on top.

[untitaker]

I got this error in asyncio debug mode:

This seems like a recent regression, and I'll fix that in 0.12.2, sorry about that

[untitaker]

0.12.2 has been released yesterday with the crash fixed

[trim21]

@untitaker yeah, I just found that. Thanks for your work.

[tomchristie]

The middleware in this SDK is a fork of encode/sentry-asgi, with the intent to deprecate sentry-asgi (afaik @tomchristie agreed to this plan). But it seems that both are now maintained?

Correct - I'd like to move encode/sentry-asgi into archived or something now.

[untitaker]

Thanks! Just wanted to make sure

[untitaker]

@tomchristie is the lifespan thing something you think we could instrument in Sentry somehow?

[tomchristie]

@untitaker I'm not quite sure what that means.

Certainly you could have "shutup" and "shutdown" event types, if that's a thing?

And yes, you could tag any errors that occur during ASGI startup/shutdown messaging against one of those two contexts.

There's also the period in the lifespan context between startup/shutdown, which app frameworks might start using for lightweight clock events, without having to reach for tools like celery, which again, yeah, could be properly tagged - though I'd need to take a more in depth look at sentry's interface as it currently stands.

[untitaker]

Nevermind my question, I looked into lifespans and now I believe my question doesn't make sense.

…

On Fri, Sep 27, 2019, 14:42 Tom Christie ***@***.***> wrote: @untitaker <https://github.com/untitaker> I'm not quite sure what that means. Certainly you could have "shutup" and "shutdown" event types, if that's a thing? And yes, you could tag any errors that occur during ASGI startup/shutdown messaging against one of those two contexts. There's also the period in the lifespan context between startup/shutdown, which app frameworks might start using for lightweight clock events, without having to reach for tools like celery, which again, yeah, could be properly tagged - though I'd need to take a more in depth look at sentry's interface as it currently stands. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#505?email_source=notifications&email_token=AAGMPRO3AMS2BBQMMRKQJFLQLX5R3A5CNFSM4IYXKOBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7YYQRY#issuecomment-535922759>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGMPRP3R3WVSYWHHZEGV7TQLX5R3ANCNFSM4IYXKOBA> .