facebook/flow · critical
Unknown exception reading from the server: {}
Error message
Unknown exception reading from the server: {} What it means
The flow CLI client reads MonitorToClientMessage frames from the running flow server over a socket. Known disconnect-style io::Error kinds are handled gracefully (spinner line cleared, Err(()) returned so the retry loop can reconnect); this panic fires for any other read error, i.e. an unexpected OS-level or decode failure while waiting for a server response.
Source
Thrown at rust_port/crates/flow_cli/src/command_utils.rs:3058
| std::io::ErrorKind::UnexpectedEof
) =>
{
if !quiet && flow_utils_tty::spinner_used() {
let stderr = std::io::stderr();
let mut stderr = stderr.lock();
flow_utils_tty::print_clear_line(&mut stderr)
.expect("failed to clear spinner line");
}
return Err(());
}
Err(e) => {
if !quiet && flow_utils_tty::spinner_used() {
let stderr = std::io::stderr();
let mut stderr = stderr.lock();
flow_utils_tty::print_clear_line(&mut stderr)
.expect("failed to clear spinner line");
}
panic!("Unknown exception reading from the server: {}", e)
}
};
match response {
MonitorToClientMessage::PleaseHold(server_status, watcher_status) => {
let status_string = {
if server_status::is_free(&server_status) {
// Let's ignore messages from the server that it is free.
// It's a confusing message for the user
if watcher_status.1 == file_watcher_status::StatusKind::Ready {
None
} else {
Some(file_watcher_status::string_of_status(&watcher_status))
}
} else {
Some(server_status::string_of_status(
use_emoji,
false,
&server_status,View on GitHub (pinned to f88ac94bcf)
Solutions
- Stop the stale server (flow stop, or kill the daemon) and rerun the command so a fresh server spawns
- Check server logs and dmesg for OOM kills or crashes; reduce memory pressure (fewer workers, smaller project, more RAM)
- Ensure the CLI and the daemon resolve to the same flow installation/version (one flow on PATH)
- If it persists, capture the underlying io::Error text from the panic and report it
Example fix
# before flow check # panics: Unknown exception reading from the server: <e> # after flow stop flow check
Defensive patterns
Strategy: retry
Prevention
- Keep exactly one flow installation so client and server versions always match
- Run flow stop after upgrading flow before starting new commands
- Watch server memory; OOM-killed servers are the most common source of mid-read failures
When it happens
Trigger: Reading a MonitorToClientMessage from the server socket returns an io::Error whose kind is not in the handled set: server crashes mid-write leaving truncated data, socket reset in an unusual way, garbage bytes causing a decode failure, or transport errors during machine suspend/resume.
Common situations: Flow server OOM-killed while processing a large check; CLI and server from different flow installations sharing a socket dir (protocol mismatch); laptop suspend/resume dropping the connection; stale daemon left running after a flow upgrade.
Related errors
- Error sending command to server: {}
- failed to dup server->monitor channel
- failed to dup monitor->server channel
- failed to write {}: {}
- failed to read executable at {} for flow build id: {}
AI-assisted analysis of facebook/flow@f88ac94bcf (2026-08-20).
Data as JSON: /api/errors/6ecaae651904b0dd.
Report an issue: GitHub.