-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporarily disable without re-initializing the client? #3112
Comments
@fiendish Here's an idea for you: you can replace the client's transport, which is responsible for sending events to Sentry, with a no-op transport while you wish for sending to be disabled, then replace the transport with the original value afterwards. Perhaps, something like the following would work for you: import contextlib, sentry_sdk
from sentry_sdk.transport import Transport
class NoOpTransport(Transport):
def capture_envelope(
self, _ # type: Envelope
):
# type: (...) -> None
pass
@contextlib.contextmanager
def sentry_sending_disabled():
client = sentry_sdk.get_client()
old_transport = client.transport
client.transport = NoOpTransport()
try:
yield
finally:
client.transport = old_transport
# Code block where you wish to disable Sentry sending:
with sentry_sending_disabled():
... # nothing that happens here will get sent to Sentry Please note, I have not tested this snippet yet, so please make sure to test it before you use it 🙂 Let me know whether this works for you! |
This issue 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 remove the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
Thank you @szokeasaurusrex! I'm now using a variant of your suggestion (
and it appears to be working. I feel vaguely uneasy about reaching into Hub.current.client instead of using get_client(), so I may belt-and-suspenders do both in case the internal Hub interface changes in the future. |
Glad to hear that this solution is working for you! Just one clarification: what Sentry SDK version are you running? 1.x or 2.x? The Also, I would strongly advise against using @contextlib.contextmanager
def sentry_sending_disabled():
# If you are on Sentry SDK 1.x, you can use sentry_sdk.Hub.current.client below, instead
client = sentry_sdk.get_client()
old_transport = client.transport
client.transport = NoOpTransport()
try:
yield
finally:
client.transport = old_transport
# Code block where you wish to disable Sentry sending:
with sentry_sending_disabled():
... # nothing that happens here will get sent to Sentry |
1.x still for now. Deprecating patterns is probably good for sentry's future, but I'll personally still need library interop across old sentry versions so won't get rid of trying to access
Heh. No worries. Though, I will note that "only meant to be" and "only able to be" are non-identical sets. In practice it actually works fine in a production prototype. But I appreciate your suggestions still and will likely steer toward something more like it in a future version. |
Problem Statement
It would be nice to have a documented simple mechanism other than reinitializing the client for disabling its transmissions.
The scenario is that I need to disable it only briefly and then reenable it again right after, but I don't have access to all of the original values that were given as part of the initial client configuration.
Solution Brainstorm
Peeking inside at the current client's contained options seems...wrong? Though if you tell me that it's fine to do so then I'll be ok with that answer too.
The text was updated successfully, but these errors were encountered: