astral-sh/ruff · error · anyhow::Error

InternalError

InternalError

Error message

request handler {error}

What it means

ty request handlers run wrapped by the routing layer; if a handler returns an error or panics, the server responds with error code -32603 (InternalError) whose message is `request handler {error}` containing the underlying anyhow error or panic payload. It almost always indicates a bug in ty or an unexpected environment condition rather than a malformed request.

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 d1087a4b9e)

Solutions

  1. Enable trace/debug logging for the server and reproduce; the log names the handler and carries the panic/error message.
  2. Update ty — handler panics are treated as bugs and fixed quickly; retest on the latest release.
  3. Minimize the triggering file (often one odd construct) and report it in the ty repository issue tracker.
  4. Restart the server if all subsequent requests fail, which suggests corrupted session state.
Defensive patterns

Strategy: try-catch

Try / catch

try {
  const res = await client.sendRequest('textDocument/hover', params);
  show(res);
} catch (e: any) {
  if (e?.code === -32603 /* InternalError */) {
    log.warn('ty failed internally', e.message); // degrade gracefully, keep editing
    return;
  }
  throw e;
}

Prevention

When it happens

Trigger: A handler panics or explicitly fails while serving a request (hover, completion, definition, etc.). The routing wrapper also logs `Encountered error when routing request with ID {id}` and may show a `ty failed to handle a request from the editor` message to the user.

Common situations: Type-checking pathological or unusual Python that trips an invariant in ty; IO failures while reading workspace files mid-request; a regression in a specific handler in a particular ty version.

Related errors

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