-
Notifications
You must be signed in to change notification settings - Fork 9.3k
Description
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") returnImpact: 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 timeoutImpact: 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
- User opens
.tsfile with syntax error - TypeScript LSP server immediately publishes diagnostics
- First diagnostic batch is skipped - user sees no errors
- User gets false impression LSP isn't working
- Only subsequent diagnostic updates show errors
Scenario B: Large Project / Slow LSP
- User edits any file in large codebase
- LSP server processes diagnostics but takes >3 seconds
- Timeout occurs - user gets incomplete or no diagnostics
- User thinks LSP failed, but it was just slow
Scenario C: Any LSP Diagnostic
- LSP server publishes diagnostic information
- 150ms debounce delay before processing
- 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:
- Removes TypeScript First-Diagnostic Skip: Processes all TypeScript diagnostics immediately
- Eliminates Diagnostic Debounce: Reduces delay from 150ms to 0ms for instant feedback
- Extends Diagnostic Timeout: Increases wait timeout from 3s to 30s to accommodate slower LSP responses
- 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
opencodeImpact 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.