valeriansaliou/sonic · error · panic

closing channel

Error message

closing channel

What it means

When the channel read loop returns an Err from the stream handling, the server logs the error and panics with 'closing channel', terminating that client's channel thread. It is a catch-all teardown for any I/O/protocol error on the connection.

Source

Thrown at server/src/channel/handle.rs:219

                        buffer.extend(read);
                    } else {
                        // Do not continue, as there is too much pending data
                        // in the buffer. Most likely the client does not
                        // implement a proper back-pressure management system,
                        // thus we terminate it.
                        tracing::error!("closing channel thread because of buffer overflow");

                        panic!(
                            "buffer overflow ({}/{} bytes)",
                            buffer.len() + read.len(),
                            MAX_LINE_SIZE
                        );
                    }
                }
                Err(err) => {
                    tracing::error!("closing channel thread with traceback: {}", err);

                    panic!("closing channel");
                }
            }
        }
    }

    fn ensure_start(&self, mut stream: &TcpStream) -> Result<ChannelMode, ChannelHandleError> {
        #[allow(clippy::never_loop)]
        loop {
            let mut read = [0; MAX_LINE_SIZE];

            match stream.read(&mut read) {
                Ok(n) => {
                    if n == 0 {
                        return Err(ChannelHandleError::Closed);
                    }

                    let mut parts = str::from_utf8(&read[0..n]).unwrap_or("").split_whitespace();

View on GitHub (pinned to e6a72da6a5)

Solutions

1. Inspect the preceding 'closing channel thread with traceback: {}' log line for the root cause
2. Fix the client to send well-formed, newline-terminated commands
3. Ensure the client closes connections cleanly and reconnects with backoff
4. Check network stability / proxies between client and server

Example fix

// client
// before
stream.write_all(payload.as_bytes()); // missing terminator, may vanish mid-write
// after
stream.write_all(format!("{}\n", payload).as_bytes())?;
stream.flush()?;

// client: ensure newline-terminated, well-formed commands
assert!(command.ends_with('\n') && !command.contains("\r\n\r\n"));

// reconnect with backoff on any channel error
loop {
    match client.ping() {
        Ok(_) => break,
        Err(_) => { sleep(backoff); backoff *= 2; reconnect(); }
    }
}

When it happens

Trigger: Any Err propagated from the stream handling inside handle_stream — e.g. TCP read failures, protocol parse errors, connection reset — while a client is attached.

Common situations: Client abruptly disconnecting mid-command; network interruption between client and server; malformed commands from a non-conforming client; socket timeouts.

Related errors

• buffer overflow ({}/{} bytes)
• write_buffer for kv must not be zero
• flush_after for kv must be strictly lower than inactive_afte
• max_background_jobs makes max_flushes unneeded, don’t config
• consolidate_after for fst must be strictly lower than inacti

AI-assisted analysis of valeriansaliou/sonic@e6a72da6a5 (2026-09-01). Data as JSON: /api/errors/08154f8d89a3e9c9. Report an issue: GitHub.