Issues, Statuses, Assignments, False Positives, and Resolution Workflow: Diagnostics, Failure Modes, and Production Practices

1. Evidence-first diagnostic sequence

1. Preserve scanner log, report-task.txt, issue/Activity evidence, and current gate.
2. Confirm SonarQube edition/version, scanner, analyzers/plugins, and instance mode.
3. Confirm exact Git revision and effective analysis parameters.
4. Confirm indexed files and report upload.
5. Confirm the exact Compute Engine task.
6. Inspect issue key, rule/profile, status, assignee, comments/tags, and new-code context.
7. Inspect authorization only when the symptom is a missing/failed workflow action.
8. Inspect database/search/JVM/container layers only if evidence points there.
9. Apply the least destructive correction and rerun the smallest equivalent scenario.

2. Failure matrix

3. Broken example: mass acceptance without review

Assume a lab operator filters all Open findings and bulk-Accepts them solely because the gate is red. Do not delete or rerun yet. Preserve the exact filter, count, Activity history, unchanged Git SHA, gate/measures before/after, and user/permission that performed the action.

Repair by reopening, then partitioning the issues by real cause: source fix, valid deferral, analyzer mistake, profile/scope mismatch, or ownership routing. The original bad action should remain visible in Activity; that is useful audit evidence.

4. Permission failure is not an analyzer failure

If a user can view an issue but cannot Accepted/False-positive it, inspect project authorization first. These actions require Administer Issues. Do not rerun scanners, change profiles, or use a global administrator token to work around an authorization symptom.

For API failures, preserve HTTP status/body and consult the current instance API documentation; the cause may be auth, permission, method/path mismatch, or deprecation.

5. “I fixed it” but the issue is still Open

Possible causes include: wrong revision scanned; wrong base directory/indexed file; the rule still detects an equivalent pattern; report uploaded but Compute Engine failed; wrong branch/project key; or an external analyzer still imports the finding. Trace revision → effective parameters → indexing → task → issue identity before touching workflow status.

6. Suppression shortcuts destroy future signal

Broad suppression can make findings disappear before normal issue workflow. Treat //NOSONAR and language suppressions as source/configuration changes with code-review impact. Never recommend mass suppression, rule deactivation, or threshold lowering as a troubleshooting shortcut.

7. Project deletion is not issue cleanup

Deleting a project destroys the history needed to explain the signal. In production it is a destructive administrative action, not a remediation technique. In this course it is allowed only as guarded cleanup of a uniquely named lab project after the evidence packet is safely preserved.

8. Production remediation record

A mature record lets another engineer reconstruct the analyzed revision, issue/rule, original status, owner, source diff or disposition rationale, reanalysis task, final status, and gate effect. That causal chain is more useful than a screenshot of a green dashboard.

Knowledge check

Official references and version notes

• Issues introduction — current issue concepts and lifecycle entry points.
• Issue management solution — identification, SCM-assisted assignment and lifecycle.
• Editing issues — Accepted/False positive, reopening, assignment, tags, comments and bulk changes.
• Retrieving issues — current issue filtering and review UI.
• Web API — bearer authentication and Web API V2 migration guidance.
• Managing tokens — token types, API use and revocation.
• SonarQube releases — dated release identities.
• SonarScanner CLI 8.1.0.6389 — scanner baseline.