neoclide/coc.nvim · info · LSPCancellationError

Request cancelled by client

Error message

Request cancelled by client

What it means

When a server responds with LSP error codes RequestCancelled (-32800) or ServerCancelled (-32802), the client re-raises the cancellation as a CancellationError (or LSPCancellationError carrying server-provided data) instead of returning the default value. This propagates intentional cancellation to the caller's token-based flow.

Source

Thrown at src/language-client/client.ts:1944

  private static RequestsToCancelOnContentModified: Set<string> = new Set([
    InlayHintRequest.method,
    SemanticTokensRequest.method,
    SemanticTokensRangeRequest.method,
    SemanticTokensDeltaRequest.method
  ])

  public handleFailedRequest<T, P extends { method: string }>(type: P, token: CancellationToken | undefined, error: any, defaultValue: T, showNotification = true): T {
    if (token && token.isCancellationRequested) return defaultValue
    // If we get a request cancel or a content modified don't log anything.
    if (error instanceof ResponseError) {
      // The connection got disposed while we were waiting for a response.
      // Simply return the default value. Is the best we can do.
      if (error.code === ErrorCodes.PendingResponseRejected || error.code === ErrorCodes.ConnectionInactive) {
        return defaultValue
      }
      if (error.code === LSPErrorCodes.RequestCancelled || error.code === LSPErrorCodes.ServerCancelled) {
        if (error.data != null) {
          throw new LSPCancellationError(error.data)
        } else {
          throw new CancellationError()
        }
      } else if (error.code === LSPErrorCodes.ContentModified) {
        if (BaseLanguageClient.RequestsToCancelOnContentModified.has(type.method)) {
          throw new CancellationError()
        } else {
          return defaultValue
        }
      }
    }
    this.error(`Request ${type.method} failed.`, error, showNotification)
    throw error
  }
  /**
   * @internal
   */

View on GitHub (pinned to 50e974d969)

Solutions

1. Check the CancellationToken passed to the request and return early when cancellation is requested
2. Catch CancellationError in the provider and return an empty/default result
3. Inspect error.data via LSPCancellationError if the server attached cancellation details
4. Avoid issuing redundant requests (debounce) so they are not cancelled

Example fix

// before
const items = await client.sendRequest(CompletionRequest.type, params, token)
// after
let items
try {
  items = await client.sendRequest(CompletionRequest.type, params, token)
} catch (e) {
  if (e instanceof CancellationError || e instanceof LSPCancellationError) return []
  throw e
}

if (token.isCancellationRequested) return defaultValue

function isLSPCancellation(e: unknown): e is LSPCancellationError {
  return e instanceof LSPCancellationError || (e as any)?.code === -32800 || (e as any)?.code === -32802
}

try {
  return await sendRequest(type, params, token)
} catch (e) {
  if (isLSPCancellation(e)) return defaultValue
  throw e
}

When it happens

Trigger: A sendRequest (e.g. completion, hover) whose server response carries code -32800 or -32802, typically because the client cancelled the request via CancellationToken or the server cancelled it and supplied optional data.

Common situations: User keeps typing so stale completion requests are cancelled; server cancels a long-running code-action or rename; the client's cancellation middleware sends $/cancelRequest and the server replies with RequestCancelled.

Related errors

• Request cancelled
• ${uri} changed before apply edit
• Unable to getCallHierarchyItem at current position
• Action "${action.title}" is disabled: ${action.disabled.reas
• Format provider not found for buffer: ${doc.bufnr}

AI-assisted analysis of neoclide/coc.nvim@50e974d969 (2026-08-31). Data as JSON: /api/errors/e90e14753d4252cb. Report an issue: GitHub.