Add ability to ignore in specific environment

[dexter-stpierre]

Summary

Add the ability to ignore issues produced by specified environments.

Motivation

In our build process we have an error that pops up redietly and I would lkike to ignore this error when it comes from development, however the same error has the possibility to pop up in production and I would like to have these errors still be tracked in production. This would help prevent non issues from coming up as regressions but also allow them to show in environments that are important

[perl5punk]

Would also love the inverse of this option, Ignore... > Until it happens for... > ENV

[mlubavin-vg]

Right, we have our test environment try to connect to other 3rd party api's test environments, and they often have issues, which we can ignore in our test environment, but we would never want to ignore in production.

This could be extremely useful

[pgrzesik]

I was about to add request for the same thing, it would really be useful to have the ability to silence errors in specific environments. 👍

[thiagoa]

I totally agree. Please, do it!

[Neaox]

This would be very helpful!

[alxgln]

This would be very very useful

[BYK]

I think the correct solution to this is skipping these events from the client using an event processor or the before_send hook.

Do you think this would address your use case?

[mlubavin-vg]

Not sure you can call that a "correct solution". A workaround that requires coding on our end, sure.

Sentry already provides some very useful filtering capability, so this wouldn't be too different. Or at least the ability to use environment in our Alert definition to not get alerts on these errors in non-prod environments

[omnipitous]

Re-up on the issue and response to BYK comment:
For my own purposes I wouldn't be streaming *anything from my lower environments to Sentry but some of my engineers really appreciate the features it provides while debugging their in-dev code SO we're sending the events across. What I want to do is not be "Alerted" about these since that has a different implication (Alerts imply urgent action or even Pages which the lower environments don't deserve) SO being able to disable the Alerts on the Sentry side for a given environment is the "correct solution" since those who want the data there at all need all of the data "sent" to Sentry just not "Alerted" on.

[BYK]

Right now I see alert rules for matching a specific environment or any environment. Sounds like what we need here is an anything but these environments option.

Not sure how easy it is to implement, especially on the UI side though. @wedamija @markstory who shall we ping for an ultimate answer on this?

[markstory]

Ignoring specific environments would require additional UI options and additional logic in the regression handling logic. None of that work is currently on any team roadmap that I'm aware of, but those plans are always very fluid.

[omnipitous]

For my current purposes the feature as implemented may do the job since the services I'm working with at the moment only have 1 production environment so "Only For Prod" instead of the current "All Environments" gets me by for now and sorry I missed that. We have 3 different "Production Like" environments so the ability to specify Alert on those and not on our 2 "lower" environments (So not even an "All but this one" but really a "Alert for these specific environments only") would still be a useful feature just not as urgent on our part if it's not in your backlog.

[b0g3r]

In my case, a few specific app's errors are completely ok for the dev environment but are red flags for the production environment. It would be great if I could use ignore the issue until it happens in production

But it's not only about alerts: I want to see all other errors in the dev environment to fix it before they'll pass to production. So, I think it's should be issue-specific setting, not a project-specific

[alondahari]

Would love it if I could configure sentry to log to the console instead of sending the event to sentry in certain environments (e.g. dev)

[Neaox]

@jazzdragon you can already do that.
In the beforeSend hook you can output the event to the console, then return null to prevent the event from being sent to Sentry.

https://docs.sentry.io/platforms/javascript/configuration/filtering/#using-beforesend

[connorads]

@BYK: I think the correct solution to this is skipping these events from the client using an event processor or the before_send hook.

Now that Sentry have kindly released the AWS Lambda Layer integration I believe this makes these sorts of code solutions/workarounds not possible in a context when Sentry is automagically integrated.

[getsentry-release]

Routing to @getsentry/workflow for triage. ⏲️

[untitaker]

re-routing this as ignoring individual issues is not within scope of relay, and given the discussion so far I don't think they're asking for a mechanism to drop data for quota management

[axilis-marko]

Is there any information on when this could be done?

[getsantry]

Routing to @getsentry/product-owners-issues for triage ⏲️

[jangjodi]

Hi axilis-marko, this similar issue #57446 is in our backlog. Unfortunately I don't have an update on when we can prioritize it.

[axilis-marko]

@jangjodi thanks for the response. Upvoted that one as well.

[jeremy-allocate]

@jangjodi As a paying customer, it's incredibly frustrating to see the most upvoted issue in the backlog go unaddressed for years. It really has me questioning how things work internally at Sentry, especially prioritization. Why even bother with a public backlog if you aren't going to listen to what your users want most? If there aren't obvious improvements to how prioritization happens, and soon, our org may have to consider moving to a different solution when our current contract is up. One of the things we value most is the response to user feedback, and I'm just not seeing enough of that in this case. Thanks for your consideration on this larger issue.

[jangjodi]

@rachrwang @Dhrumil-Sentry seeing that this is a highly requested feature, is this something we can prioritize in the near future?

[henrycjc]

This would be a great improvement. We are looking at ways to implement this ourselves, and it is proving difficult to build a robust solution.

[cobyeastwood183]

https://sentry.zendesk.com/agent/tickets/144475