astral-sh/ruff · error · Error

InternalError

InternalError

Error message

request handler {error}

What it means

A request handler ran but returned an error that is not a salsa cancellation; api.rs wraps it as `request handler {error}` and responds with LSP InternalError, also surfacing a message to the editor ('ty failed to handle a request...'). The inner cause is only visible in the server's tracing log.

Source

Thrown at crates/ty_server/src/server/api.rs:400

            tracing::debug!(
                "request id={} method={} was cancelled by salsa, re-queueing for retry",
                request.id,
                request.method
            );
            client.retry(request);
        } else {
            tracing::debug!(
                "request id={} was cancelled by salsa, sending content modified",
                id
            );
            respond_silent_error(id.clone(), client, R::salsa_cancellation_error());
        }
    } else {
        respond::<R>(
            id,
            Err(Error {
                code: lsp_server::ErrorCode::InternalError,
                error: anyhow!("request handler {error}"),
            }),
            client,
            log_guidance,
        );
    }
}

fn sync_notification_task<N: traits::SyncNotificationHandler>(
    notif: server::Notification,
) -> Result<Task> {
    let (id, params) = cast_notification::<N>(notif)?;
    Ok(Task::sync(move |session, client| {
        let _span = tracing::debug_span!("notification", method = %N::METHOD).entered();
        if let Err(err) = N::run(session, client, params) {
            tracing::error!("An error occurred while running {id}: {err}");
            client.show_error_message(format!(
                "ty encountered a problem. {}",
                session.client_name().log_guidance()

View on GitHub (pinned to 672bb4edf0)

Solutions

  1. Check the server log (stderr/tracing) for the inner `{error}` cause — that is the real failure
  2. Retry the same request after edits settle (transient races usually clear)
  3. Update ty; internal handler errors are frequently fixed bugs
  4. If reproducible, minimize the file + keystrokes and file a ty issue with the log
Defensive patterns

Strategy: retry

Try / catch

// TS: retry once after a short delay, then surface the toast only once
async function requestSafe<T>(method: string, params: unknown): Promise<T | null> {
  for (let attempt = 0; attempt < 2; attempt++) {
    try { return await client.sendRequest(method, params); }
    catch (e: any) {
      if (e?.code !== -32603) throw e;
      await sleep(250);
    }
  }
  return null;
}

Prevention

When it happens

Trigger: Any unexpected failure inside a handler: a file deleted between didOpen and hover, invalid state after rapid edits, a bug in the handler, or an unwound panic in a background request task.

Common situations: Hover/completion racing a file rename or git branch switch, very large or corrupt files, or a genuine ty bug — the user sees an error toast from the editor.

Related errors


AI-assisted analysis of astral-sh/ruff@672bb4edf0 (2026-08-16). Data as JSON: /api/errors/7fbc93a601bb3015. Report an issue: GitHub.