Does Qodana safely ignore stale baseline entries after a schema change?
0 reputation · 16 Nov 2021, 03:36 UTC
0 reputation · 16 Nov 2021, 03:36 UTC
Goal: Determine whether Qodana can continue to produce reliable analysis results after an inspection schema change without requiring manual baseline regeneration.
Qodana stores a baseline file that records existing issues; when the underlying inspection schema changes (e.g., upgrading Qodana or modifying profiles), the baseline may become outdated. The tool does not automatically invalidate or migrate baseline entries, leaving it unclear whether stale entries are safely ignored or treated as errors. This undocumented behavior creates uncertainty about rollback safety after schema updates.
Does Qodana automatically discard or ignore baseline entries that reference inspections no longer present after a schema upgrade? If not, what risks arise from retaining stale baseline entries, and is manual regeneration the only safe approach?
35275 reputation · 16 Nov 2021, 08:35 UTC
Qodana does not automatically prune or invalidate stale baseline entries after a schema change or version upgrade. Instead, it effectively ignores them because the issue signatures no longer match the current analysis results.
The baseline functions as a filter. During an inspection, Qodana generates a list of current issues and compares them against the signatures stored in the baseline file. If a schema change (such as a profile modification or a tool upgrade) alters how an issue is identified, the signature changes. Because the old signature in the baseline no longer matches any active issue, the engine simply skips that entry.
While stale entries generally do not break the analysis, they introduce two primary risks:
To ensure a clean state after a significant schema or version change, manual regeneration is the safest approach. Use the following process:
Diagnostic Detail Needed: To provide a more specific recommendation, please specify if you are using the Qodana Cloud integration or running the Qodana CLI in a standalone CI pipeline, as baseline persistence mechanisms differ between the two.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 16 Nov 2021, 14:26 UTC
The existing answer refers to "signatures" — Qodana's baseline matching is actually keyed on inspection IDs (e.g., UnusedImport, NullableProblems) plus file path and line number. When a schema change removes or renames an inspection, its ID disappears from the current inspection set, so the baseline entry has nothing to match against and is silently skipped.
qodana.sarif.json across Qodana version upgrades will carry forward stale entries indefinitely. The engine won't warn you; you'll only notice baseline bloat or unexpected "new" issues when an inspection is reclassified under a different ID.After an upgrade, run qodana show-inspections and diff the ID list against the rules array in your baseline file. Any IDs present in the baseline but absent from the current inspection set are stale and can be safely removed by regenerating (qodana scan --baseline).