Sentry appears to not send exceptions that happen in async context

[takeda]

Environment

How do you use Sentry? self-hosted 9.1.2

Which SDK and version? Python 1.1.0

Steps to Reproduce

I have an AWS lambda that has multiple entry points. I use following wrappers on the handler functions so I can use async code:

def async_entrypoint(func: Any) -> Any:  # pragma: no cover
    @wraps(func)
    def wrapper(event: Dict[str, Any], context: LambdaContext) -> Dict[str, Any]:
        sentry_sdk.init(
            "https://<snip>",
            integrations=[AwsLambdaIntegration(timeout_warning=True)],
            release=__version__,
        )
        return asyncio.run(func(event, context))

    return wrapper

It appears that functions that use this wrapper when they crash they don't seem to trigger notification in sentry. At first I had the init inside an async function and thought that maybe init() need to be called in sync code. So I moved it here, but that didn't seem to fix the issue. Am I doing something wrong?

[ahmedetefy]

Hey @takeda Thanks for opening the issue

sentry_sdk.init needs to be called on import, on module level for Sentry to work.

If you have data dependencies i.e. DSN for example that are only accessible within your entrypoint, you can initialise the sdk (call sentry_sdk.init) on module level without the dsn for example, and then re-initialise it again in your entrypoint

Let me know if this solves your issue

[takeda]

I'll test that with new release, but is the reason for this requirement that maybe I never called it, or is it that there's something init() does that required to be called in a global scope?

The reason from calling in from inside of a function was mostly because I had code that extracted version and also used this to disable sentry for unit tests, although I resolved both of those issues, but am still curious.

[ahmedetefy]

Yeah, it is required to call init on module level for our monkey patches to run asap but then the transport/client can be set up later through your subsequent init call after you have extracted your version

[takeda]

@ahmedetefy looks like after making the mentioned change the issue continues to persist

So I invoked init() on the module level with integrations parameter then later, then later invoked it with the same integrations, url and release version. I just had a crash that never made it to sentry.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[antonpirker]

Hi @takeda Could you supply code for a sample Lambda function where I could reproduce this? Thanks!

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[takeda]

The current setup of sentry was configured just for my team and it is currently broken and not fixed due to other priorities, so I'm unable to provide more debugging information, but an example lambda was provided in the original comment.

[antonpirker]

Thanks for the update @takeda!

We are currently working on a new version of the serverless integration, so maybe we can also work on this in the next couple of weeks.

[takeda]

@antonpirker so my team we didn't have enough resources to maintaining self-hosted sentry, and we also were unable to convince management why we should use hosted version, so we can't use sentry anymore (bummer, because it is very useful, especially with lambda applications).

Anyway, in the mean time dealing with another issue I learned that using asyncio.run() in lambda entry points it is generally a bad idea, as the lambda code continue to run for some time, and call entry point over again. asyncio.run() opens new event loop and closes it on completion which can create all kind of weird issues in such environment.

I'm quite certain that the issue I was experiencing was due to that, and things likely would work right if I replaced asyncio.run() with asyncio.get_event_loop().run_until_complete()

Anyway I'm closing this, as I believe this was my bug.

[antonpirker]

Hey @takeda !

Thanks for coming back to us! And really sad that you can not use Sentry anymore!

Maybe the docs here provide some information for you to convince management to switch to Sentry Saas: https://docs.sentry.io/product/sentry-basics/migration/ There is also a USD 100,-- credit if you switch from self hosted, to make it easier to switch over.

We also are working on having a region in the EU. So if GDPR and data residency is an issue, until the end of the year it should be possible to have all the Sentry data in the EU.