glzr-io/glazewm · warning
Failed to send response
Error message
Failed to send response: {} What it means
`IpcServer::process_message` executes a client command and then pushes the result back through the per-client `response_tx` channel. If the receiving end is gone (client disconnected) or the channel is closed, `send` fails and the error is wrapped as "Failed to send response". It indicates the response could not be delivered, not that the command itself failed.
Solutions
- Keep the client (or its receiver) connected until the response arrives; await the response message before closing the WebSocket.
- In the client, handle disconnects gracefully and treat this server-side bail as a lost response, not a command failure.
- Re-send the command if a response is required and the connection dropped.
- If writing wm-ipc-client code, ensure the connection stays open for the request duration (don't drop/reconnect mid-request).
- Check server logs for concurrent shutdown while requests are in flight; delay `stop()` until pending messages are processed.
Example fix
// before (client) client.send_command(msg); client.disconnect(); // after let response = client.send_command(msg).await?; client.disconnect();
Defensive patterns
Strategy: retry
Validate before calling
fn connection_alive(client: &IpcClient) -> bool { client.is_connected() } Try / catch
match client.send_command(msg).await {
Ok(resp) => resp,
Err(e) if e.to_string().contains("Failed to send response") => {
// reconnect and retry once
client.reconnect().await?;
client.send_command(msg).await?
}
Err(e) => return Err(e),
} Prevention
- Keep the IPC connection open until the response arrives.
- Don't fire-and-forget commands over the WebSocket if you need results.
- Reconnect cleanly after network drops before re-sending.
When it happens
Trigger: A WebSocket client sends a command then disconnects before `process_message` finishes, so the response channel's receiver is dropped; or the server is shutting down and the response channel was closed.
Common situations: Short-lived CLI invocations where the client times out or exits early; network drops mid-request; automated scripts firing fire-and-forget commands and closing the connection immediately.
Related errors
- Failed to send event
- IPC connection closed unexpectedly.
- WebSocket error
- Unsupported IPC command.
- Root container does not have a position.
AI-assisted analysis of glzr-io/glazewm@5709ad0a3c (2026-09-08).
Data as JSON: /api/errors/f7bb306fbd395ebf.
Report an issue: GitHub.
Appendix: source
Thrown at packages/wm/src/ipc_server.rs:163
let response_data =
app_command
.map_err(anyhow::Error::msg)
.and_then(|app_command| {
self.handle_app_command(
app_command,
response_tx,
disconnection_tx,
wm,
config,
)
});
// Respond to the client with the result of the command.
response_tx
.send(Self::to_client_response_msg(message, response_data)?)
.map_err(|err| {
anyhow::anyhow!("Failed to send response: {}", err)
})?;
Ok(())
}
#[allow(clippy::too_many_lines)]
fn handle_app_command(
&self,
app_command: AppCommand,
response_tx: &mpsc::UnboundedSender<Message>,
disconnection_tx: &broadcast::Sender<()>,
wm: &mut WindowManager,
config: &mut UserConfig,
) -> anyhow::Result<ClientResponseData> {
let response_data = match app_command {
AppCommand::Query { command } => match command {
QueryCommand::Windows => {
ClientResponseData::Windows(WindowsData {
View on GitHub (pinned to 5709ad0a3c)