Statuses

After creation, issues flow through a lifecycle, taking on one of five possible statuses:

• Open - set by SonarQube on new issues

• Confirmed - set manually to indicate that the issue is valid

• Resolved - set manually to indicate that the next analysis should Close the issue

• Reopened - set automatically by SonarQube when a Resolved issue hasn't actually been corrected

• Closed - set automatically by SonarQube for automatically created issues.

Resolutions

Closed issues will have one of two resolutions:

• Fixed - set automatically when a subsequent analysis shows that the issue has been corrected

• Removed - set automatically when either the related coding rule or the file is no longer available. The rule may not be available either because it has been removed from the profile or because the underlying plugin has been uninstalled. The file could be unavailable because it has been removed from the project, moved to a different location or renamed.

Resolved issues will have one of two resolutions:

• False Positive - set manually

• Won't Fix - set manually

Issue workflow

Issues are automatically closed (status: Closed) when:

• an issue (of any status) has been properly fixed => Resolution: Fixed

• an issue no longer exists because the related coding rule has been deactived or is no longer available (ie: plugin has been removed) => Resolution: Removed

Issues are automatically reopened (status: Reopened) when:

• an issue that was Resolved (but Resolution is not False positive) is shown by a subsequent analysis to still exist

Understanding which issues are "new"

To determine the creation date of an issue, an algorithm is executed during each analysis to determine if an issue is new or existed previously. This algorithm relies on line content hashes (excluding whitespace) the issue is reported on. For multi-line issues, we are using the hash of the first line. For each file (after detection of file renaming), the algorithm takes the list of base issues from the previous analysis, and tries to match with raw issues reported by the new analysis. The algorithm tries to first match using the strongest evidence, and then fallback to weaker heuristics.

• if the issue is on the same rule, with the same line number and with the same line hash (but not necessarily with the same message) > MATCH

• detect block move inside file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) > MATCH

• on the same rule, with the same message and with the same line hash (but not necessarily with the same line) > MATCH

• on the same rule, with the same message and with the same line number (but not necessarily with the same line hash) > MATCH

• on the same rule and with the same line hash (but not the same message and not the same line) > MATCH

Unmatched "base" issues are closed as fixed.

Unmatched "raw" issues are new.

Purging Closed Issues

By default, Closed issues are kept for 30 days. For more details, browse the Housekeeping documentation.