fix(core): add LSP diagnostics caching and document refresh fallback

[vadimLuzyanin]

TLDR

Fixes missing LSP diagnostics by caching textDocument/publishDiagnostics notifications and using them as a fallback when textDocument/diagnostic pull requests fail. Also adds document refresh (didClose + didOpen) to trigger fresh analysis from the LSP server.

Screenshots / Video Demo

N/A — internal change, verified end-to-end: the fixed build reports all TypeScript diagnostics while the original build returns none. Full flow confirmed in a single session: diagnose → fix → re-diagnose.

Dive Deeper

The LSP textDocument/diagnostic pull request fails on some LSP servers (e.g., typescript-language-server in certain configurations), leaving users with no diagnostics. This change adds a push-based fallback: LspServerManager now listens to publishDiagnostics notifications from the server and caches them. When the pull fails, NativeLspService force-refreshes the document (didClose + didOpen) and reads from the cache, with a 5s timeout via Promise.race. The same cache is also used as a fallback for workspaceDiagnostics when workspace/diagnostic fails, filtered by workspace root URI.

Reviewer Test Plan

Create a TypeScript file with intentional type errors in a workspace with .lsp.json configured for typescript-language-server. Run with --experimental-lsp and ask for diagnostics — should report all errors. Add another error to the file and ask again — should include the new error. Then ask the CLI to fix the errors and re-check diagnostics — should report zero remaining.

Testing Matrix

	🍏	🪟	🐧
npm run	❓	❓	✅
npx	❓	❓	❓
Docker	❓	❓	❓
Podman	❓	-	-
Seatbelt	❓	-	-

Linked issues / bugs

Fixes #3029

[wenshao]

[Suggestion] handle.cachedDiagnostics.delete(uri) runs unconditionally before the if (openedForServer?.has(uri)) check. If the URI is not tracked in openedDocuments, the refresh block is skipped entirely but the cache entry has already been destroyed — valid cached diagnostics are lost.

Suggested change

	const openedForServer = this.openedDocuments.get(name);
	if (openedForServer?.has(uri)) {
	handle.cachedDiagnostics.delete(uri);
	openedForServer.delete(uri);

— qwen3.6-plus via Qwen Code /review

[wenshao]

[Suggestion] Removing the URI from openedForServer before the async refresh creates a race window. During the delay(), a concurrent ensureDocumentOpen call would see the URI as "not opened" and send a duplicate didOpen, which is undefined behavior per the LSP spec.

Consider keeping the URI in openedForServer and using a separate "refreshing" Set to track URIs currently being refreshed.

— qwen3.6-plus via Qwen Code /review

[wenshao]

[Suggestion] The pendingDiagnostics Map stores a single { resolve } per URI. If two callers invoke diagnostics() for the same URI concurrently, the second .set() overwrites the first caller's resolver. When the notification arrives, only the second caller resolves; the first hangs until the 5s timeout.

Consider storing an array of resolvers per URI:

Suggested change

	setTimeout(() => {
	const pending = handle.pendingDiagnostics.get(uri);
	if (!pending) {
	handle.pendingDiagnostics.set(uri, { resolves: [] });
	}
	handle.pendingDiagnostics.get(uri)!.resolves.push(resolve);

And resolve all in the notification handler.

— qwen3.6-plus via Qwen Code /review

[wenshao]

[Nice to have] DEFAULT_LSP_DOCUMENT_OPEN_DELAY_MS * 5 is a magic number with no comment explaining why 5x is needed. If the base constant changes, this delay changes proportionally which may not be intended.

Consider defining a named constant like LSP_DIAGNOSTIC_REFRESH_DELAY_MS = 1000.

— qwen3.6-plus via Qwen Code /review

[wenshao]

[Nice to have] handle.pendingDiagnostics.clear() silently drops all pending resolvers. Any in-flight diagnostics() callers waiting on Promise.race will hang for the full 5s timeout instead of failing fast.

Consider rejecting all pending resolvers with a "server restarted" error before clearing the map.

— qwen3.6-plus via Qwen Code /review

[huww98]

Reaching here for missing diagnostics from gopls (Golang LSP). I wonder if we can fix this by sending textDocument/didChange or textDocument/didSave after edit tool? This looks simpler, and should not invalidate too much cache by close and re-open file. (Not tested yet, just my guess)