SonarQube analysis retries: overwrite the same branch key or use a distinct key per attempt?

Question

A CI pipeline needs to retry a SonarQube analysis step when a run fails transiently, and the goal is that a resubmitted report produces exactly one current analysis per build — no duplicated issue counts and no polluted measure history.

Two documented approaches exist. Re-running the scanner with the identical sonar.projectKey and sonar.branch.name replaces the previous analysis for that branch. Alternatively, each attempt can use a distinct branch name or pull-request key, which stores every attempt separately.

The constraint is that the Compute Engine processes reports asynchronously, so a retry decision may be made while an earlier task is still pending or has failed partway through. Whether leftover state from a failed task interferes with a resubmission under the same coordinates appears version-sensitive, and deleting a stale branch to remove its issues has purge timing that varies by edition and version.

For automated retries, is overwriting the same branch coordinates the safer default, or does a distinct key per attempt better isolate failed runs?
What task state should be confirmed before resubmitting under the same branch coordinates?
Does deleting a short-lived branch reliably remove its issues across editions, and how does that affect cleanup for per-attempt keys?

Wasi · Answer

Direct answerFor automated retries, overwriting the same sonar.projectKey + sonar.branch.name (or sonar.pullrequest.key) is the safer default. SonarQube’s Compute Engine treats a new report for an existing branch as a replacement: the previous analysis is marked obsolete and its issues/measures are superseded once the new task finishes successfully.Why distinct keys are not recommended for routine retriesEach attempt creates a separate branch/PR entry, inflating issue counts and polluting measure history.Cleanup then requires manual or scripted deletion of every short‑lived branch.Only use distinct keys when you need to preserve a failed run for forensic comparison.Required task‑state check before resubmittingQuery the Compute Engine task queue for the target branch:GET /api/ce/task?componentId=&branch=Wait until the latest task for that branch shows status=SUCCESS or status=FAILED/CANCELED.Do not resubmit while a task is PENDING or IN_PROGRESS; overlapping submissions can be discarded or merged unpredictably depending on version.Branch deletion and cleanupDeleting a short‑lived branch via the UI or /api/project_branches/delete removes its issues and measures from leak‑period calculations immediately in Developer, Enterprise, and Data Center editions (9.9 LTS+).Background purge of raw measures and snapshots may take a few minutes; a recreated branch with the same name can briefly show stale data in some API responses.Community Edition has no branch/PR analysis — every scan targets the main branch, so retries always overwrite the single project analysis.Practical verification stepsIn a non‑production project, run a scan, note the task ID, then immediately resubmit with identical coordinates.Confirm via /api/ce/task that only the second task ends in SUCCESS and the branch shows only the second analysis’s issues.Check SonarQube version and edition in Administration → System → System Info to ensure branch/PR analysis is available.One diagnostic detail that changes the recommendationWhat SonarQube version and edition are you running? (Behavior described applies to 9.9 LTS and 10.x; pre‑8.9 versions had less deterministic replacement semantics.)

SonarQube analysis retries: overwrite the same branch key or use a distinct key per attempt?

1 answer

Direct answer

Why distinct keys are not recommended for routine retries

Required task‑state check before resubmitting

Branch deletion and cleanup

Practical verification steps

One diagnostic detail that changes the recommendation

Your perspective belongs here.

1 question comment

When to Overwrite vs. Isolate