A regression is a bug that was fixed and has started happening again, or behavior that worked and a later change broke. The defining feature is direction: this code used to be correct, and now it is not.
Regressions cost more than new bugs because nobody is looking for them. A new error gets triaged. A returning one arrives in a feed where somebody already ticked the box.
Example
An item resolved in v4.2.1 goes quiet for three weeks. Then v4.3.0 changes how the invoice payload is built upstream, and the identical exception class and stack trace come back from the untouched serializer:
KeyError: 'amount'
at serialize_invoice (/app/api/serializers.py:61)
The new occurrence carries the same fingerprint as an item someone already marked resolved, so this item is a regression. The engineer who shipped the v4.2.1 fix should pick it up first, because they know which fix stopped holding and can check the v4.3.0 change against it.
What Rollbar does about regressions
Rollbar reactivates a resolved item automatically when a new occurrence matching its fingerprint arrives, moving the item’s status from Resolved back to Active. Rollbar records that as Reactivated, a state transition distinct from Reopened, which is the manual change a person makes in the UI, so the two are separable in notification rules. Rollbar evaluates any Item Reactivated notification trigger at that moment, which is how a returning bug reaches Slack or PagerDuty without anyone watching the feed.
Rollbar’s own documentation suggests using this deliberately. Mark an item Resolved when you believe you have fixed it, and let Rollbar tell you if you have not.
Related terms
Catch regressions after every deploy.
Sources
- Rollbar Docs, Rollbar Terminology: https://docs.rollbar.com/docs/rollbar-terminology
- Rollbar Docs, Deploy Tracking: https://docs.rollbar.com/docs/deploy-tracking
