Sentry: Don't mark a resolved issue as regressed upon a report from a browser with an old release

[dmnd]

Here's a proposal for dealing with obsolete releases:

1. See a Sentry issue in Javascript
2. Fix the bug
3. Deploy the fix to production
4. Mark the Sentry issue as resolved
5. A user with a long-lived tab triggers the issue again

What happens: Sentry re-opens the issue as "regressed" even though it knows the report was from an obsolete release.

Expected: Sentry records the error, but does not re-open the issue unless further reports occur in an up-to-date release.

[dcramer]

This is def something we should figure out. It's basically "Resolved in [this|previous] release". It might make sense to make this the default resolved behavior, but than the complexity is if the error isn't a code error -- such as a database connection error -- it doesnt get resolved from code changes.

It's possible though in that same situation the logic of "ignore old releases" would be fine.

[dmnd]

The only situation I can think of where "ignore old release" will hide legit errors is if you have a zombie worker process running old code due to a bad deploy. Maybe that's OK? Or maybe "ignore old releases" is javascript specific?

[benvinegar]

@dmnd Since you posted this, we've since introduced new features for choosing which releases the fix is introduced in (e.g. "Mark as resolved in "). Closing, but I'll re-open if you feel those changes don't address your concerns.

[dmnd]

Thanks @benvinegar!