Hey @drvalani, you can check the IP address of the request (presumably this will be one from your internal network?) and set a different fingerprint if you identify the request to come from a smoke test. This will create a separate issue for smoke-test related errors which you can mute.
How this works in detail depends on which SDK you use.
I like the idea of creating separate issues for smoke-test related errors. Is it possible to differentiate by passing say a value in the HEADER (ie, x-source: “smoke-test”) value rather than on IP?
Also @untitaker what does this mean “set a different fingerprint”.
@zeeg Smoke Tests can run at the same time as when real traffic is coming in, are you saying just to capture all events as smoke tests during this period?
before_send allows you to modify the event shortly before it is sent to sentry. Fingerprints are a way to fix how events are grouped into issues if the default behavior is undesirable.
Something like this should work for Flask:
from flask import request
def is_a_smoke_test(request):
# check headers, IP address, whatever
def before_send(event, hint):
if request and is_a_smoke_test(request):
# remove {{default}} if you want to group all smoke test
# errors together (regardless of exception type)
event['fingerprint'] = ["{{default}}", "smoke-test"]
# return None # uncomment to just drop the event
return event
sentry_sdk.init(before_send=before_send)
You can also add tags or change the environment the same way
Yeah I’d probably suggest doing an environment or tag over fingerprint, otherwise you’re going to have some weird behavior in Sentry. A failing smoke test - after all - should be on the same degree as a real failure.
@zeeg I think the issue is that the smoke test is not actually failing, but rather they have events for each 401 which are asserted via the smoke test.