Finding Reconciliation Across Reviews
When an MR receives multiple pushes, Buzzbin needs to know whether an earlier finding is still valid or was fixed by the new changes. Finding reconciliation compares previous findings with the latest review output.
Why reconciliation matters
Without reconciliation, a finding can remain open after the code was fixed. That clutters the MR and can unnecessarily block auto-approval or internal gates.
When a finding is considered fixed
An earlier finding is auto-resolved only when both conditions are true:
- The relevant code region changed in the new push.
- The latest review did not raise the same finding again on the same file, overlapping line range, and category.
This rule is conservative. If the code region was not touched, Buzzbin does not assume the issue was fixed. If the issue is raised again, the finding is still live.
How findings match
Buzzbin treats findings as matching when they share:
- normalized file path
- category
- overlapping line range
Severity and confidence are not part of identity, because the same issue may be scored differently in a later review.
What happens after a fix
If the previous finding has a GitLab thread, Buzzbin attempts to resolve that thread. It also records resolution time, reason, and SHA in the database. If the GitLab thread-resolve side effect fails, the database remains the source of truth and the job does not fail because of that side effect.
Relationship to approval
Auto-approval counts only open blocking findings. Once reconciliation resolves a blocking finding, it no longer blocks approval. If a human resolves the thread in GitLab, Buzzbin persists that resolved state in the database too.
What is never reopened
Buzzbin does not unresolve a resolved finding. If the same issue is introduced again later, the latest review creates a new finding and thread, while the old resolved row remains as audit history.