Ignore errors that occur in temporary environments #168
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We sometimes spin up temporary environments (e.g. 'test-pink-aws') while developing applications. If there are errors in those apps, we can accidentally send many thousands of errors to Sentry, which can mean we hit rate limits on our other, production, environments, as we have a single shared Sentry account. This commit introduces a `active_sentry_environments` config property, which is checked against the SENTRY_CURRENT_ENV ENV variable. If an error occurs in an environment we care about, it is reported to Sentry, otherwise it gets ignored. There is prior art for this - in #160 we added a similar check, such that if a particular error occurs during the nightly data sync, it gets ignored. I've made sure this new functionality is compatible with what's already been added. Trello: https://trello.com/c/GfFwJG0K/2180-investigate-disabling-sentry-on-environments-we-dont-care-about-timebox-2-days
MuriloDalRi
approved these changes
Oct 27, 2020
MuriloDalRi
approved these changes
Oct 27, 2020
ChrisBAshton
added a commit
that referenced
this pull request
Jun 8, 2021
The custom option `active_sentry_environments` was added in #168. However, it turns out there is already a native option for this: `enabled_environments`. See https://docs.sentry.io/platforms/ruby/configuration/options/ This allows us to simplify our code a fair bit. I've also removed the stubbed `sending_allowed?` method as it was interfering with some tests and giving a false sense of security. We're now providing all of the necessary configuration for the `Sentry::Configuration` instance to return `true` on its `valid?` method, so no need for the hack. Each config option is documented in an inline comment as otherwise it can be quite obtuse.
ChrisBAshton
added a commit
that referenced
this pull request
Jun 8, 2021
The custom option `active_sentry_environments` was added in #168. However, it turns out there is already a native option for this: `enabled_environments`. See https://docs.sentry.io/platforms/ruby/configuration/options/ This allows us to simplify our code a fair bit. I've also removed the stubbed `sending_allowed?` method as it was interfering with some tests and giving a false sense of security. We're now providing all of the necessary configuration for the `Sentry::Configuration` instance to return `true` on its `valid?` method, so no need for the hack. Each config option is documented in an inline comment as otherwise it can be quite obtuse.
ChrisBAshton
added a commit
that referenced
this pull request
Jun 8, 2021
The custom option `active_sentry_environments` was added in #168. However, it turns out there is already a native option for this: `enabled_environments`. See https://docs.sentry.io/platforms/ruby/configuration/options/ This allows us to simplify our code a fair bit. I've also removed the stubbed `sending_allowed?` method as it was interfering with some tests and giving a false sense of security. We're now providing all of the necessary configuration for the `Sentry::Configuration` instance to return `true` on its `valid?` method, so no need for the hack. Each config option is documented in an inline comment as otherwise it can be quite obtuse.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We sometimes spin up temporary environments (e.g. 'test-pink-aws')
while developing applications. If there are errors in those apps,
we can accidentally send many thousands of errors to Sentry, which
can mean we hit rate limits on our other, production,
environments, as we have a single shared Sentry account.
This commit introduces a
active_sentry_environmentsconfigproperty, which is checked against the SENTRY_CURRENT_ENV ENV
variable. If an error occurs in an environment we care about,
it is reported to Sentry, otherwise it gets ignored.
There is prior art for this - in #160 we added a similar check,
such that if a particular error occurs during the nightly data
sync, it gets ignored. I've made sure this new functionality is
compatible with what's already been added.
Trello: https://trello.com/c/GfFwJG0K/2180-investigate-disabling-sentry-on-environments-we-dont-care-about-timebox-2-days