Edit on GitHub
When a merged PR results in a bug
This page describes the process to follow when someone notices a mistake in a merged pull request (PR).
- A contributor (either staff or community member) submits a PR, it is reviewed and merged into the codebase.
- Sometime later, the community notices a mistake with the PR.
Question is, what should we, as a community, do? That depends on the scope of the changes in the PR that was merged.
Low impact issues
A low impact PR might mean that it affected:
- Some non-critical functionality.
- It doesn’t affect users in a substantial way.
If this is the case, do the following:
- Capture details in an issue.
- Mark it according to its priority.
- Would be best to assign it to the person who introduced the issue in the first place.
High impact issues
A high impact PR represents something that has or will result in a customer incident.
If this is the case, there are two scenarios:
- The feature introduced in the PR is handled by a feature flag.
- The feature introduced in the PR is not handled by a feature flag.
For scenario 1, if it’s not affecting other functionality, turn that feature flag off to disable the feature.
For scenario 2:
- Revert the changes introduced in the original PR.
- Notify the person who worked on the PR know so they can work on a proper fix for their PR.
- Reintroduce the change through the regular PR cycle.