LSP diagnostics are skipped or delayed under multiple conditions #12288

Bug Description

OpenCode systematically skips or delays LSP diagnostics under multiple conditions, even when LSP servers are running and providing diagnostic information. This affects user experience and can give false impression that LSP is not working properly.

Identified Skip Conditions

1. TypeScript First-Diagnostic Skip

Location: packages/opencode/src/lsp/client.ts:60

if (!exists && input.serverID === "typescript") return

Impact: First diagnostic publication from TypeScript Language Server is completely ignored
Affected Files: .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts
User Impact: Real TypeScript errors are missed during initial file analysis

2. Diagnostic Wait Timeout

Location: packages/opencode/src/lsp/client.ts:231

}, 3000, // 3-second timeout

Impact: Diagnostic collection times out after 3 seconds, missing slower LSP responses
Affected Servers: All LSP servers (TypeScript, Python, Go, Rust, etc.)
User Impact: Incomplete diagnostic information for large projects or slower machines

3. Diagnostic Debounce Delay

Location: packages/opencode/src/lsp/client.ts:16, 227

const DIAGNOSTICS_DEBOUNCE_MS = 150
setTimeout(() => {
  unsub?.()
  resolve()
}, DIAGNOSTICS_DEBOUNCE_MS)

Impact: 150ms delay added to all diagnostic publications to wait for follow-up diagnostics
Affected Servers: All LSP servers
User Impact: Delayed feedback, less responsive development experience

Current Behavior Scenarios

Scenario A: TypeScript File Edit

1. User opens .ts file with syntax error
2. TypeScript LSP server immediately publishes diagnostics
3. First diagnostic batch is skipped - user sees no errors
4. User gets false impression LSP isn't working
5. Only subsequent diagnostic updates show errors

Scenario B: Large Project / Slow LSP

1. User edits any file in large codebase
2. LSP server processes diagnostics but takes >3 seconds
3. Timeout occurs - user gets incomplete or no diagnostics
4. User thinks LSP failed, but it was just slow

Scenario C: Any LSP Diagnostic

1. LSP server publishes diagnostic information
2. 150ms debounce delay before processing
3. User experiences noticeable lag in error feedback

Expected Behavior

LSP diagnostics should be processed immediately and reliably when servers are available, regardless of:

• File type or language server
• Timing of diagnostic publication (first vs subsequent)
• Processing speed of LSP server

Proposed Solution

Add new environment flag OPENCODE_RESPECT_LSP_DIAGNOSTICS=true that when enabled:

1. Removes TypeScript First-Diagnostic Skip: Processes all TypeScript diagnostics immediately
2. Eliminates Diagnostic Debounce: Reduces delay from 150ms to 0ms for instant feedback
3. Extends Diagnostic Timeout: Increases wait timeout from 3s to 30s to accommodate slower LSP responses
4. Maintains Backward Compatibility: Default behavior unchanged when flag is not set

Implementation Details

• Flag: OPENCODE_RESPECT_LSP_DIAGNOSTICS=true
• Scope: Affects diagnostic processing only, not server startup or configuration
• Non-Intrusive: Respects existing LSP server configurations and settings
• Opt-In: Users must explicitly enable the flag

Usage

export OPENCODE_RESPECT_LSP_DIAGNOSTICS=true
opencode

Impact Assessment

• User Experience: Immediate and reliable LSP diagnostic feedback
• Performance: No impact on LSP server performance, only processing timing
• Compatibility: Fully backward compatible, optional enhancement
• Scope: Benefits all language servers, not just TypeScript

This addresses the systematic pattern of LSP diagnostic skipping/delaying while maintaining existing behavior as default.