Sentry interceptor example

[nediamond]

What was changed

added Sentry interceptor example based on discussion in slack thread

Why?

Sentry is a popular error monitoring tool & interceptors aren't super intuitive to make from scratch, hopefully this can be a good starting point for folks

Checklist

1. How was this tested:
   Executed locally

2. Any docs updates needed?
   not sure

[CLAassistant]

All committers have signed the CLA.

[cretz]

Added a couple of comments. Looks great!

Some other that I think would help:

• Add a README.md in this folder w/ details on how to run (see how OTel sample does it in OpenTelemetry sample #18)
• Add a "dependency group" for sentry in pyproject.toml to add the sentry_sdk dependency (see how OTel sample does it in OpenTelemetry sample #18)
• Separate the starter from the worker. We are doing this in all of the non-hello samples, and we do it in all SDKs, to emphasize that workers are often completely separate from starters (see how OTel sample does it in OpenTelemetry sample #18)

If the Sentry SDK comes with utilities to capture/assert output in a test, a test in tests/sentry would be great. But not required or anything.

[nediamond]

will try to implement the tests/readme/worker changes this weekend

[cretz]

@nediamond - Wanted to follow up here. I think this is a great sample. Let me know if there's anything I can do to help move it along.

[nediamond]

@cretz sorry got busy with life stuff will set some time aside for this before next week - feel clear on what needs to be done thanks

[nediamond]

@cretz i reverted the poetry.lock file bc it looked like the checks didnt like it - could use your help generating that since it seems like it may be from a difference in my setup or something

added a super basic readme, but i think this is about as much as i can commit to for now

[cretz]

could use your help generating that since it seems like it may be from a difference in my setup or something

added a super basic readme, but i think this is about as much as i can commit to for now

Ok, I will look to fixing that and improving your README

[nathanielobrown]

Hey @nediamond and @cretz, I just wanted to share a pitfall I found in this approach for implementing Sentry via interceptors when using threaded activities. Because activities are run in a thread in a ThreadPoolExecutor or in a separate process but the interceptor is run in the main thread, the activity code gets a totally different Sentry scope/context than the interceptor. So any context generated inside the activity (such as breadcrumbs, setting tags, context etc.) will not be included in the resulting Sentry issue. I also was experiencing some "leakage" of contexts, where transaction names would be wrong (I don't 100% understand what was happening there). I haven't tested with async activities, but I feel like maybe they might have the same issue too because Sentry uses contextvars?

My solution was to add Sentry handling to a custom decorator that wraps the @activity.defn decorator and does Sentry handling in the thread. I left the activity interceptor as a fallback, and set an attribute on the activity function and skip interceptor Sentry handling if this attribute is set.

I just wanted to write this up in case you had any further thoughts on this and as a note for others implementing Sentry with Temporal Python SDK.

[cretz]

Hrmm, this is true. I think we need to be putting contextvars from interceptors on to threaded activities. I have opened temporalio/sdk-python#263.