WHY

Two main use cases:

• temporary configuration mistake: some rules were disabled / project was associated to wrong QP / language plugin was not installed after a migration / files were excluded...
• temporary code change: some code was temporarily dropped

In these two cases, analyzing a project closes some/all issues. Analyzing again the project once the mistake is fixed, all issues come back as new. Issues lose their history and can pollute the leak period as well as the Quality Gate status.

WHAT

The issue tracking algorithm should be improved in order to look at closed issues as a last fallback. An old issue should then be "reverted" to the state it had before it was closed, retrieving all the manual changes that were applied: FP/WF status, comments, assignee, severity and type.

In order to avoid any wrongly reopened closed issue, the issue matching must be done as exactly as possible (same line, same line hash, same rule, same message, etc.).

Only issues closed in 30 days (the default value of sonar.dbcleaner.daysBeforeDeletingInactiveShortLivingBranches) before the current day should be taken into account:

• the older a closed issue gets, the higher the risk of reopening it inappropriately increases
• use cases to cover are temporary situations, which implies closed issues should be recovered after a reasonably short period of time

Regarding branches and PR, only closed issues of the current long living branch should be taken into account.

Technical discussion

Retrieving the closed issue from DB

When doing issue tracking, open issues are loaded by one SQL select per component. To load closed issues, we can either load them in the same statement or load them in a specific one.

The former option implies:

• closed issues are loaded even if not needed (ie. all issues of the component are matched to existing open issues)
• avoid going from one SQL statement per component to 2 in some cases, but its always larger if there is closed issues (ie. there is an impact even if processing an analysis with little to no change)

The later option implies:

• closed issues are loaded only if needed (ie. there is at least one issue on the component not matched to an existing one). Therefor, when processing a report where most component have no new issue, there won't be any extra cost coming from the change in this ticket
• if a component has at least one really new issue, then the SQL for closed issue is done anyway and without benefits

Regarding "look at closed issues as a last fallback"

• there is currently no "priority" between issues when looking for matches.
  • either we implement this kind of priority
  • or issue tracking on closed issues should be done in a separate extra tracking run in case there is at least one left unmatched by the run on open issues

Option 1 is probably the most efficient option in term of tracking but it requires to retrieve closed issues at the same time as open issues. Only option 2 is compatible with retrieving closed issues only if needed (and with a specific SQL request).

When an issue is closed, the following happens:

• resolution is set to either REMOVED (disabled rule) or FIXED
• status is set to CLOSED
• line is set to null (because this information usually is misleading, see SONAR-6364)
• closeDate and updateDate are updated

This implies the following:

1. for issue tracking on closed issue to be done on exact matches, the line number is needed but it is currently deleted when issue is closed
   • we should drop this behavior: line should be kept in DB but removed from WS responses => the consequences of this solution are not under control => discarded
   • in order to not break the reason why the line was deleted, a new changelog entry will be adding when closing the issue, storing the line number
   • as a consequence, the feature of this ticket will only work for closed issues created AFTER this ticket is deployed
2. because resolution is changed, we can't tell whether the issue was a WONT FIX or FP before being closed
   • this information should be retrieved from the change log
3. closeDate should be set to null when reopening (with a changelog entry added)
4. a change log entry must be added indicating that issue was reopened
5. closed issues may have an assignee
   • when assignee is non null, it should stay as is
   • when assignee is null (issue was unassigned), then the issue must stay unassigned
     • assignee is not removed when user is deactivated so that issues get assigned by to the user if user reactivated later. This behavior should be kept when reopening closed issues.

Regarding issue notifications:

• there is no concern regarding "new issue" notification as the issue not new
• "Changes in issues assigned to me" may be triggered and sent out by the current code
  • if so, and unless the notifications are incorrect, let's keep it that way. Otherwise, it's ok the notifications are not sent

Regarding Sonarlint and issue tracking in connected mode

While the feature would totally make sense in SonarLint, it is out of scope of this ticket.

Regarding hotspots and manual vulnerability

Hotspots and manual vulnerabilities are a different kind, they have a specific issue workflow and life cycle. Maybe reopening their closed issues makes sense. Maybe it's preferable to not reopen them, or with the exact states they had when they were closed. They were considered late when working on this ticket and for the sake of simplicity, they will be ignored and the reopening won't apply to them.

Regarding branches/PRs

Feature won't be available on:

• short living branches
• pull requests
• first analysis of a long living branch based on another one (ie. a secondary long living branch)
  • because in this case, there is no closed issue in current branch and of course we shouldn't take into account closed issues of base branch

it will be available on:

• main branch on second analysis and later
• long living branches on second analysis and later

HOW

The way issues are closed today must be updated:

• a change log entry is added with the last know line of the issue

Note: this implies that only closed issue created after this ticket is fixed will have the ability to be reopened

"Changes in issues assigned to me" notifications must be checked whether they are sent for closed issues and whether they are correct.

Issue tracking is done on closed issues:

• closed in the last 30 days
  • NICE-TO-HAVE make the number of of days configuration but keep it an hidden feature. That will provide a way to mitigate an issue with the feature in production – which can come in handy both for SonarCloud and services
• not a hotspot nor a manual vulnerability
• on the current component for the current branch/pr only
• after tracking on open issues, therefor only if there is at least one issue left on the component without a existing issue match
• only with exact issue tracking (same line, same line hash, same rule, same message)

When reopening a closed issue:

• a changelog is added logging the reopening
• the following properties are set to the latest known value from the changelog (there can be none)
  • status
  • resolution
  • line
• closeDate is set to null and a changelog for this change added
• the assignee is untouched (whether it is null or not)
• as for open issues, locations and similar fields are updated to the value from the report