What causes "LSP request not supported by this transport" in Hmbown/CodeWhale?

Use a transport that implements `request` (e.g. StdioLspTransport)

LSP request not supported by this transport

Error message

LSP request not supported by this transport

What it means

The default `LspTransport::request` implementation returns this error for transports that only support diagnostics. Full JSON-RPC request/response (definition, symbols, references) is unsupported there, so any caller attempting a semantic request against such a transport fails immediately.

Solutions

Use a transport that implements `request` (e.g. StdioLspTransport)
Check the transport's capability before issuing semantic requests and degrade gracefully
Implement `request` for your custom transport

Example fix

// before
let reply = transport.request("textDocument/definition", params, wait).await?;
// after
let reply = match transport.request("textDocument/definition", params, wait).await {
    Ok(v) => v,
    Err(e) if e.to_string().contains("not supported") => return fallback_symbol_lookup(),
    Err(e) => return Err(e),
};

Defensive patterns

Strategy: fallback

Validate before calling

const supportsRequests = typeof transport.request === 'function' && transport.implementsRequests === true;

Type guard

fn supports_semantic(t: &dyn LspTransport) -> bool { t.capabilities().semantic_requests }

Try / catch

match transport.request(method, params, wait).await {
    Ok(v) => Ok(v),
    Err(e) if e.to_string().contains("not supported") => fallback_lookup(),
    Err(e) => Err(e),
}

Prevention

Advertise transport capabilities explicitly and check before semantic calls
Route semantic requests only to StdioLspTransport
Provide a non-LSP fallback for definition/symbol lookups

When it happens

Trigger: Calling go-to-definition/document-symbols/references (or `request_for_document`) on a diagnostic-only or fake LSP transport that has not overridden `request`.

Common situations: Running with a minimal/diagnostic LSP integration; tests using fake transports; a server integration that never implemented the request path.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/b709cd047a0f5d98. Report an issue: GitHub.

Appendix: source

Thrown at crates/tui/src/lsp/client.rs:109

pub trait LspTransport: Send + Sync {
    /// Notify the server that a file was opened or its contents updated, then
    /// wait up to `wait` for a `publishDiagnostics` notification for that
    /// file. Returns the diagnostics list (possibly empty). Implementations
    /// must NOT block past `wait`.
    async fn diagnostics_for(
        &self,
        path: &Path,
        text: &str,
        wait: Duration,
    ) -> Result<DiagnosticPublication>;

    /// Send a JSON-RPC request and wait up to `wait` for the reply.
    ///
    /// Default returns "unsupported" so diagnostic-only fakes keep working.
    /// Real transports implement this for go-to-definition, symbols, and
    /// references without spawning a second server lifecycle.
    async fn request(&self, _method: &str, _params: Value, _wait: Duration) -> Result<Value> {
        Err(anyhow!("LSP request not supported by this transport"))
    }

    /// Synchronize and query one document atomically when the transport can
    /// prove that ordering. Diagnostic-only/legacy transports stay unverified.
    async fn request_for_document(
        &self,
        path: &Path,
        text: &str,
        method: &str,
        params: Value,
        wait: Duration,
    ) -> Result<SemanticReply> {
        timeout(wait, async {
            self.ensure_open(path, text).await?;
            Ok(SemanticReply {
                result: self.request(method, params, wait).await?,
                document_version: None,
            })

View on GitHub (pinned to 73e0f67d83)