What causes "Cannot resolve issue at line {} of {} due to: {}" in SonarSource/sonarqube?

Re-run analysis after confirming the file/issue state; the stale transition will simply be dropped.

Cannot resolve issue at line {} of {} due to: {}

Error message

Cannot resolve issue at line {} of {} due to: {}

What it means

During analysis, SonarLint-anticipated issue transitions (e.g. 'wont-fix' status applied in the IDE) are replayed server-side against stored issues. When an issue cannot be resolved to an existing DB issue at its reported line (it was deleted, moved, or the line no longer matches), the transition fails and this warning is logged and surfaced as a CE task message. It is non-fatal: the analysis continues, only that issue's transition is skipped.

Source

Thrown at server/sonar-ce-task-projectanalysis/src/main/java/org/sonar/ce/task/projectanalysis/issue/TransitionIssuesToAnticipatedStatesVisitor.java:97

        performAnticipatedTransition(issue, matchedRaws.get(issue));
      }
    }
  }

  private static boolean isEligibleForAnticipatedTransitions(DefaultIssue issue) {
    return issue.isNew() && STATUS_OPEN.equals(issue.getStatus()) && null == issue.resolution();
  }

  private void performAnticipatedTransition(DefaultIssue issue, AnticipatedTransition anticipatedTransition) {
    try {
      issueLifecycle.doManualTransition(issue, anticipatedTransition.getTransition(), anticipatedTransition.getUserUuid());
      String transitionComment = anticipatedTransition.getComment();
      String comment = Strings.isNotBlank(transitionComment) ? transitionComment : "Automatically transitioned from SonarLint";
      issueLifecycle.addComment(issue, comment, anticipatedTransition.getUserUuid());
      issue.setBeingClosed(true);
      issue.setAnticipatedTransitionUuid(anticipatedTransition.getUuid());
    } catch (Exception e) {
      LOGGER.warn(TRANSITION_ERROR_TEMPLATE, issue.getLine(), issue.componentKey(), e.getMessage());
      ceTaskMessages.add(
        new CeTaskMessages.Message(getMessage(issue, e),
          Instant.now().toEpochMilli(),
          MessageType.GENERIC));
    }
  }

  private static String getMessage(DefaultIssue issue, Exception e) {
    final int MAX_LENGTH = 50;
    int componentKeyLength = issue.componentKey().length();
    String componentKey = componentKeyLength > MAX_LENGTH ? ("..." + issue.componentKey().substring(componentKeyLength - MAX_LENGTH, componentKeyLength)) : issue.componentKey();
    return String.format(TRANSITION_ERROR_TEMPLATE.replace("{}", "%s"), issue.getLine(), componentKey, e.getMessage());
  }
}

View on GitHub (pinned to 184c821202)

Solutions

Re-run analysis after confirming the file/issue state; the stale transition will simply be dropped.
Refresh SonarLint issue synchronization for the project so anticipated transitions match current server issues.
Check that the branch analyzed is the same one the IDE session was bound to.
Inspect the full warn log line to identify the component and line; verify the issue exists via api/issues/search.
If noise persists, disable SonarLint issue status sync or update SonarLint/plugin versions.

Example fix

// before (comment lost / mismatched issue)
// nothing to change server-side; re-sync
// after
// In SonarLint: right-click project > 'Sync security hotspots and issue status', then re-run CI analysis

Defensive patterns

Strategy: fallback

Validate before calling

// before relying on SonarLint transitions, confirm the issue still exists on the server
curl -u $TOKEN: "$SONAR_URL/api/issues/search?componentKeys=$COMPONENT&issues=$ISSUE_KEY"

Try / catch

// server-side: transitions are skipped with a warning; treat the CE task message as informational
// client-side (tooling): re-check issue state after analysis
if (issueNotFound(issueKey)) { refreshSonarLintSync(); }

Prevention

Keep SonarLint and its connected mode in sync with the server version.
Avoid long gaps between IDE sessions and CI analyses on actively edited files.
Analyze the same branch used in SonarLint connected mode.
Monitor background-task messages rather than failing builds on this warning.

When it happens

Trigger: SonarLint synchronized an issue status/comment in the IDE, but at analysis time the corresponding issue cannot be resolved: the component's issue at that line is gone, lines shifted, or rule/issue key mapping fails.

Common situations: Developer closed or marked 'won't fix' in SonarLint, then the file was edited before CI analysis; issues were purged between analyses; SonarLint and server versions/branch differ so the issue mapping is stale.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors

AI-assisted analysis of SonarSource/sonarqube@184c821202 (2026-09-09). Data as JSON: /api/errors/74aef397d42ca7cd. Report an issue: GitHub.