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

  1. Keep the client (or its receiver) connected until the response arrives; await the response message before closing the WebSocket.
  2. In the client, handle disconnects gracefully and treat this server-side bail as a lost response, not a command failure.
  3. Re-send the command if a response is required and the connection dropped.
  4. If writing wm-ipc-client code, ensure the connection stays open for the request duration (don't drop/reconnect mid-request).
  5. 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

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


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)