Anton Pirker

Not yet, sorry

@mihalikv can you confirm that the problem is gone when up update to Sentry SDK version 2.18.0 or newer?

As for solar schedules: we currently only support `crontab` and `schedule` schedules in Celery, for everything else we print a warning: https://github.com/getsentry/sentry-python/blob/antonpirker/trace-origin-in-integrations/sentry_sdk/integrations/celery/beat.py#L90

About the invalid Celery crontab definition. We probably need to improve our transaction from Celery crontab definition to the one we send to Sentry implemented here: https://github.com/getsentry/sentry-python/blob/antonpirker/trace-origin-in-integrations/sentry_sdk/integrations/celery/beat.py#L67-L75

i thought about that too. but garbage collection moves objects around. so id(exc) could be different when we safe it and when we compare it...

The `id()` of an object is [guaranteed to never change](https://docs.python.org/3/library/functions.html#id) during the life cycle of the object. So taking it.

I will close this in favor of https://github.com/getsentry/sentry-python/pull/4809 Reason: Python reuses memory addresses after garbage collection. Making this path unreliable.

Hey @artempronevskiy ! Does this also happen if your run it with CPython, or only in pypy? (We do not support pypy officially, so the code is not tested against...

Just saw that the original poster said it is not related to the Sentry SDK. Will close this.

Hey @AltafHussain4748 ! Your code looks good, I think the only thing your are missing that you need to [enable tracing](https://docs.sentry.io/platforms/python/tracing/). (Setting `tracing_sample_rate=1.0` in your `init()` call.) You can check...