Unresolved results need their own status because a timeout, unsupported language, or indexing race is not the same as proving a vulnerable function is unreachable. If teams collapse those states, tool failure becomes a false negative. A separate unknown state preserves auditability and forces human review only where the evidence is incomplete.
Why unresolved results need their own status
Unresolved language-server results are a different state from “verified unreachable.” A timeout, unsupported language, stale index, or parse failure means the scanner did not finish with enough evidence to decide. Giving that condition its own status preserves the difference between “not proven” and “proven absent,” which is essential when the result drives review, triage, or audit decisions.
A separate status also helps teams keep tool behavior visible. Language servers fail in ways that are operational, not semantic: the code may be fine, the index may be incomplete, or the query may have been malformed. If those outcomes are collapsed into a single negative result, the report looks cleaner than the evidence really is.
That matters because security and quality workflows often consume the status as a gate. A false negative created by a timeout can silently suppress follow-up on a real issue, while a distinct unknown state tells reviewers that the control did not complete and that a human decision is still required.
What the status should communicate to reviewers
The most useful unresolved state answers one practical question: did the analysis fail, or did it simply not reach a confident conclusion? Reviewers need to see whether the tool was blocked by environment conditions, by language support, or by missing project context. Those causes imply different next steps, from rerunning the index to falling back to manual inspection.
The status should also preserve auditability. A record that says “unresolved” is more honest than a record that implies no issue exists when the engine never had enough data to decide. In practice, that makes the report suitable for change review, exception handling, and later root-cause analysis when results fluctuate across runs.
This is especially important in mixed or evolving codebases, where unsupported syntax, generated files, or partially indexed repositories are common. A status that captures uncertainty gives teams a way to measure scanner completeness instead of mistaking coverage gaps for clean findings.
How to use the status without weakening the control
Unresolved should be treated as “needs follow-up,” not as “safe.” That keeps the status conservative without turning every incomplete run into a blocker. The useful distinction is whether the tool failed to prove absence, not whether it produced a noisy result.
Teams should also avoid overloading the status with too many meanings. If it represents timeout, unsupported language, parse error, and indexing race all at once, the label is still useful, but the surrounding metadata has to carry the reason code. Otherwise, the same status becomes too vague to prioritize remediation or identify whether the issue belongs to the scanner, the repository, or the pipeline.
When the workflow is used for assurance, unresolved results should be counted separately from confirmed negatives and confirmed positives. That makes coverage visible and prevents reporting from rewarding incomplete automation as if it were a valid security conclusion.
Practitioner Guidance
What to prioritize: Separate confidence from conclusion. If the language server did not complete normally, keep the result distinct from “no issue found” and attach a reason code so operators can tell timeout, unsupported syntax, and indexing failure apart.
What to verify: Make sure the status survives into downstream reporting, dashboards, and audit logs. If unresolved results are normalized away before review, the control loses the very evidence that explains why a finding is incomplete.
Common mistake: Treating an incomplete scan as a clean pass. That is the fastest route to a false sense of coverage, especially in repositories with changing dependencies or partial language support.
Practitioner takeaway: The unresolved state is not just a UI detail, it is a control boundary. Use it to preserve honesty about evidence quality, then decide separately whether the next action is rerun, manual review, or exception acceptance.