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 🥀

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

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)

What is the status of this PR?

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

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?

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 why are there so many test changes in this PR now? can you summarize them?

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.

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 anton.pirker@sentry.io and I will send you something! Thanks!

Thanks @antonpirker for the heavy lifting!