Would be helpful to have function decorators for transactions and spans

[markstory]

The current context managers for starting transactions and marking spans are great. However, there have been a few cases where having decorators for transactions and spans would make code simpler to understand. For example celery tasks could be written like

@celery.task
@sentry_sdk.transaction(transaction="celery.update.user" op="job")
def update_user(user_id):
    # Do things

Has less visual noise than the decorator does, and when adding/removing instrumentation the entire function doesn't change. The same idea applies to spans:

@sentry_sdk.span(description="github.fetch_users", op="github.api")
def fetch_github_users(...):
    # do the api request and data transformations.

The names of the decorators in this issue are likely rubbish, but I think supporting decorators will help make adding instrumentation simpler for end users as it generates less noisy differences and reduces the amount of indentation in their code.

[untitaker]

Yup, has been brought up a couple times. I feel like we may only want this for spans for now. For transactions I feel like the decorator could push a scope and set an error boundary at the same time as well

…

On Mon, Jul 13, 2020, 21:52 Mark Story ***@***.***> wrote: The current context managers for starting transactions and marking spans are great. However, there have been a few cases where having decorators for transactions and spans would make code simpler to understand. For example celery tasks could be written like @***@***.***_sdk.transaction(transaction="celery.update.user" op="job")def update_user(user_id): # Do things Has less visual noise than the decorator does, and when adding/removing instrumentation the entire function doesn't change. The same idea applies to spans: @sentry_sdk.span(description="github.fetch_users", op="github.api")def fetch_github_users(...): # do the api request and data transformations. The names of the decorators in this issue are likely rubbish, but I think supporting decorators will help make adding instrumentation simpler for end users as it generates less noisy differences and reduces the amount of indentation in their code. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#760>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMPRJB7ZDDYZ5YO2OPVATR3NQXHANCNFSM4OYZZRHQ> .

[ynouri]

My team is currently adopting Sentry for our Python code base and have been feeling the need for a decorator too. The main goal is to make it easier to start tracing any arbitrary function, and make the business logic more readable by removing instrumentation code.

We came up with the decorator implementation attached in draft PR #1089.

Does this match with what you had in mind by any chance?

PS: I'm new to Sentry and to the sentry-python code base, apologies in advance if this proposal misses obvious features or edge cases!

[ynouri]

Also curious if there are any existing alternatives or workarounds for this - we didn't mean to re-invent the wheel.

[ynouri]

We have been using those decorators in production on a Python 3.8 FastAPI app for a few months now and they seem to get the job done.

I would be willing to push the PR to the finish line (linting, unit tests) but would prefer to get feedback first. @untitaker any thoughts?

[brettc]

I'm starting to add some custom spans to our FastAPI app, and my immediate thought was: "where are the decorators for this?" What is the status of the PR #1089 ? (and thanks @ynouri, I'll cut and paste your code for now).

[alecgerona]

Hey all, since this is merged, any chance we can update the docs as well to show how to use these decorators?

[antonpirker]

Hey @alecgerona

Have a look at this documentation: https://docs.sentry.io/platforms/python/performance/instrumentation/custom-instrumentation/

There is described how to use the decorators to create spans. (We do not have a decorator to create transactions)
I guess we can close this issue now.