Fix LSP crash on unparseable cell option YAML by handling null lint result

[juliasilge]

Fixes #1118 (the upstream report is from posit-dev/positron#15965)

This PR fixes a Quarto LSP server crash that occurred when saving a document containing unparseable YAML in code cell options (for example, a %%| fig-cap: value containing an unquoted colon). After five crashes in three minutes, the client stops restarting the server and all language features are lost until reload.

Root cause

When cell option YAML fails to parse, getLint() in the bundled vs-code.mjs module catches the resulting YAMLException, logs "Error found during linting", and resolves to null. The on-save diagnostics path in provideYamlDiagnostics then called .map() on that null value, throwing a TypeError that crashed the language server:

Error found during linting [YAMLException: bad indentation of a mapping entry ...]
TypeError: Cannot read properties of null (reading 'map')
    at computeOnSaveDiagnostics (.../lsp.js)

The other caller of getYamlDiagnostics (in apps/lsp/src/custom.ts) already handled null correctly, which is why this only crashed on save.

I verified against the reproduction document in #1118, and now saving no longer crashes the server.

A possible follow-up

With this fix, a document with broken cell option YAML silently produces no YAML diagnostics on save (the parse error is only logged to the Output channel). A future improvement could surface the parse error as a diagnostic using the position info in the YAMLException; that requires changes in the Quarto CLI, where the exception is currently swallowed. The null guard here is still valuable regardless.

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[lionel-]

Since having to handle nulls everywhere is a bit of a footgun, or at least impractical, I'd normalise at the boundary by wrapping getLint() with ?? [] here:

quarto/apps/lsp/src/quarto.ts

Line 53 in 73a528d

getYamlDiagnostics: quartoModule.getLint,

Then we'd keep the current non-nullable signature in the Quarto interface.

WDYT?

[juliasilge]

Oh, that's a better idea, @lionel-. Reworked in de07dbf:

• Reverted the call-site guard in diagnostics-yaml.ts and the nullable signature on the public Quarto interface
• initializeQuarto now wraps the external getLint() with ?? [] to normalize at the boundary
• Kept Promise<Array<LintItem> | null> on the private QuartoYamlModule interface

[lionel-]

LG!