[BUG] Experimental LSP tool returns empty results instead of initialization errors for nested Rust workspace

Description

Summary

The experimental OpenCode LSP tool is exposed and callable, but it does not produce usable Rust workspace results for a valid nested Cargo project. More importantly, apparent infrastructure or initialization failure is surfaced as an authoritative empty answer ([], [null], or No results found) rather than as an error.

That makes it difficult for a coding agent to distinguish “this symbol genuinely has no references” from “the language server never loaded the workspace.”

Environment

• OpenCode: 1.18.12
• OS: Windows 11
• Language server: rust-analyzer, installed through the Rust toolchain
• Repository layout:

<git-root>/tethers-0.1/host-rust/Cargo.toml

The Rust crate is nested below the Git repository root.

OpenCode was launched in a fresh console process with process-local environment variables:

OPENCODE_EXPERIMENTAL_LSP_TOOL=true
OPENCODE_DISABLE_LSP_DOWNLOAD=true

The real OpenCode CLI executable was used, not the desktop GUI executable.

Observed behaviour

For known Rust functions, fields, and symbols that definitely exist and have references:

• goToDefinition returned No results found
• findReferences returned No results found
• hover returned [null]
• documentSymbol returned no results
• workspaceSymbol returned no results
• opencode debug lsp document-symbols <valid-file-uri> returned [] with exit code zero
• a second fresh targeted session, using real zero-based positions at known call sites, timed out after approximately 244 seconds without usable LSP output

The same definitions and references were immediately discoverable with rg, and the Rust project compiled and passed its complete test suite.

Why this is risky

The current result shape does not distinguish between:

1. a successful query with zero results;
2. rust-analyzer not starting;
3. the wrong workspace root being selected;
4. Cargo metadata or workspace initialization failing;
5. the document not being opened or indexed;
6. indexing still being in progress;
7. the request timing out or the client/server bridge failing.

An agent may therefore treat a language-server failure as valid code-navigation evidence and make an unsafe edit.

Expected behaviour

When the language server or workspace is not ready, the LSP tool should return an explicit error or status rather than an empty successful result.

Ideally the tool would expose enough diagnostic state to identify:

• selected workspace root;
• language-server process status;
• initialization or Cargo metadata errors;
• whether the file belongs to the loaded workspace;
• whether indexing is still in progress;
• request timeout.

A bounded timeout would also be preferable to a request hanging for several minutes.

Suggested fallback behaviour

If OpenCode cannot prove that the server is initialized and the document/workspace is loaded, return a clear failure such as:

LSP unavailable: rust-analyzer did not initialize this workspace

rather than [], [null], or No results found.

The feature is marked experimental, so occasional failure is understandable. The important issue is that failure currently looks indistinguishable from a valid empty answer.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response