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
- Check the server log (stderr/tracing) for the inner `{error}` cause — that is the real failure
- Retry the same request after edits settle (transient races usually clear)
- Update ty; internal handler errors are frequently fixed bugs
- 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
- Keep the server's tracing log accessible — the InternalError text the client sees hides the real cause
- Retry transient requests (hover, completion) once after edits settle before reporting
- Pin a known-good ty version; check release notes for handler-fixing patches
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
- InvalidParams
- Failed to get the current working directory while creating a
- MethodNotFound
- InvalidParams
- client exited without proper shutdown sequence
AI-assisted analysis of astral-sh/ruff@672bb4edf0 (2026-08-16).
Data as JSON: /api/errors/7fbc93a601bb3015.
Report an issue: GitHub.