Qodana JVM resource-leak inspection: baseline legacy findings or gate on severity counts?

Direct Recommendation

Use baseline mode for existing findings and add a low absolute failThreshold as a backstop. This blocks new resource-leak findings while allowing legacy leaks to be cleaned up gradually.

Why This Hybrid Works

Baseline mode (baseline: true in qodana.yaml) records current findings in baseline.xml and only fails the gate on new problems. That prevents a leak pattern from silently passing after a fix. However, baseline alone lets the legacy count grow if developers ignore it. Adding a tight absolute threshold (e.g., ERROR: 0, WARNING: 5) caps net‑new leaks and forces gradual remediation of baselined items.

Implementation Steps

1. Pin the linter image in CI (e.g., jetbrains/qodana-jvm:2024.3). Do not use latest.
2. Run once locally to capture the exact inspection ID and default severity for that version:

   docker run --rm -v $(pwd):/data jetbrains/qodana-jvm:2024.3 --show-report

   Inspect qodana.sarif.json → rules[] for a rule whose name or shortDescription contains "ResourceLeak" or "resource leak". Note the ruleId (typically ResourceLeak or JavaResourceLeak) and defaultConfiguration.level (usually "warning").
3. Create the baseline (commit this file):

   docker run --rm -v $(pwd):/data jetbrains/qodana-jvm:2024.3 --baseline baseline.xml

4. Configure qodana.yaml with both mechanisms:

   version: 1.0
   baseline: true
   failThreshold:
     error: 0
     warning: 5
     # weakWarning: 10  # optional, if you want to track lower‑severity drift
   profile:
     name: qodana.recommended
     # Optionally restrict to the specific inspection ID you verified:
     # include:
     #   - name: ResourceLeak   # or JavaResourceLeak
   

5. Verify the gate: introduce a new unclosed Closeable in a test branch; the gate should fail. Confirm baselined findings do not fail the gate.

What Changes the Recommendation

If your team must achieve zero resource‑leak findings within a fixed sprint (e.g., compliance deadline), drop the baseline and set failThreshold: { error: 0, warning: 0 } immediately. That forces a one‑time cleanup but accepts temporary gate failures.

Assumptions & Uncertainty

• Inspection ID and default severity are version‑specific. The IDs ResourceLeak / JavaResourceLeak and severity WARNING are typical for 2024.x releases, but you must verify against your pinned image’s SARIF.
• Baseline files are path‑sensitive; renaming/moving source files can resurface baselined findings as "new".
• Static analysis only catches Closeable/AutoCloseable not closed on some control‑flow path. It does not detect heap retention, off‑heap/native leaks, listener leaks, or cache eviction failures.

One Missing Diagnostic Detail

Which exact linter image tag will you pin? (e.g., 2024.3, 2025.1, 2025.2-eap). The inspection ID and default severity must be confirmed against that specific version’s report before the gate config is final.