Add decorator for Sentry tracing

[ynouri]

Draft proposal for https://github.com/getsentry/sentry-python/issues/760

[github-actions[bot]]

This pull request 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 🥀

[ynouri]

This pull request 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 🥀

I would be happy to bring this to the finish line but probably best to get feedback from a maintainer first. Thank you

[janfabry]

Would it be better to have a separate decorators for transactions and spans? They have different concerns.

The transaction decorator:

• Would ensure a transaction exists
• Would overwrite the name (if passed)
• Would ensure a passed sampled argument is adhered to (if True is passed, but the existing tx is not sampled, it should restart the transaction - because if you start with sampling disabled I think you can't enable it later on, the SpanRecorder is not enabled) (calling the decorator sentry_traced when it does not ensure it actually is traced is confusing)

The span decorator:

• Would start a new span, with the passed args
• Would only work if a transaction exists, but would not care if it doesn't

Maybe you could also have a decorator that combines both of these, but then it needs a clear name.

(I'm struggling with these questions right now as we are designing the decorators for our use case, so maybe it's a useful brain dump, but if not, feel free to ignore it)

[mschfh]

What is the status of this PR?

[ynouri]

I would be happy to bring this to the finish line but probably best to get feedback from a maintainer first. I moved it from Draft to Ready for Review. Maybe it'll get picked up by someone with this new status. cc @sl0thentr0py

[antonpirker]

Hey @ynouri !

Great work! I have moved the decorator into the tracing package and renamed it to align with how this is named in other Sentry SDKs.

We would need tests for the decorator, could you please write some?

[antonpirker]

Hey @ynouri I will change the API, ab bit, because we have some things that should be working the same over different programming languages.

Also the span.op should not be set to an arbitrary value because we index spans based on this so we have a fixed set we can choose: https://develop.sentry.dev/sdk/performance/span-operations/

(I will change your code to set it to function)

[antonpirker]

I have now removed the creation of the transaction in your decorator and also set the span op always to function. I know this might now frustrate you because you did a lot of good work, and now I come along and delete half your code. Just be assured, that we really appreciate your contribution, but as Sentry has to support a lot of platforms and versions we have some constraints. Sorry for that.

One thing that we need to fix now: Python 2.7 does not understand the async def something() definition of a function. I am trying to figure out now, how the decorator can support sync functions in python 2 and 3 and async functions only in python 3.

[antonpirker]

This is the updated documentation: https://github.com/getsentry/sentry-docs/pull/6439

[antonpirker]

If you could have a look @sl0thentr0py , would be great.

There is some duplicated code but this is necessary so the decorator works in Python 2 and in Python 3 with sync and async functions.

[sl0thentr0py]

@antonpirker why are there so many test changes in this PR now? can you summarize them?

[antonpirker]

Because I now install pytest_asyncio for running the common tests some tests (like test_asyncio) have been run for the first time (they where not run at all before) and this lead to some broken tests.

Now I changed the test setup to have a "common" test environment that is kind of like an integration, so I can install pytest_asyncio to only this "common" tests without having it also there in all the integration tests.

[antonpirker]

Hey @ynouri !

Thanks for the great contribution and the patience! Finally we have merged your contribution!

If you want to have a small gift for your work, please send me your shipping address and your t-shirt size to [email protected] and I will send you something! Thanks!

[ynouri]

Thanks @antonpirker for the heavy lifting!