Daemon child: failed to connect to parent in-socket (child w

Error message

Daemon child: failed to connect to parent in-socket (child write end): {}

What it means

Second half of the daemon child's reconnect: TcpStream::connect to parent_in_addr (the child's write end) must succeed after the out-socket connected. This panic fires when that connect fails: the parent exited/closed the second listener between the two connects, loopback connects are refused/rate-limited, or the sandbox blocks the additional connection.

Source

Thrown at rust_port/crates/flow_daemon/src/daemon.rs:554

        panic!(
            "Daemon child: failed to connect to parent out-socket (child read end): {}",
            e
        )
    });
    child_in_sock.set_nodelay(true).unwrap_or_else(|e| {
        panic!(
            "Daemon child: failed to set TCP_NODELAY on parent out-socket: {}",
            e
        )
    });
    child_in_sock.write_all(&token).unwrap_or_else(|e| {
        panic!(
            "Daemon child: failed to write token to parent out-socket: {}",
            e
        )
    });
    let mut child_out_sock = TcpStream::connect(parent_in_addr).unwrap_or_else(|e| {
        panic!(
            "Daemon child: failed to connect to parent in-socket (child write end): {}",
            e
        )
    });
    child_out_sock.set_nodelay(true).unwrap_or_else(|e| {
        panic!(
            "Daemon child: failed to set TCP_NODELAY on parent in-socket: {}",
            e
        )
    });
    child_out_sock.write_all(&token).unwrap_or_else(|e| {
        panic!(
            "Daemon child: failed to write token to parent in-socket: {}",
            e
        )
    });

    exec(&entry_name, child_in_sock, child_out_sock, param_bytes);

View on GitHub (pinned to f88ac94bcf)

Solutions

Retry the command after flow stop to reset daemon state
Verify the parent process stays alive through spawn (check its logs/crash reason)
Loosen loopback connection-rate limits in sandboxes if applicable
Report if it reproduces deterministically with a given sandbox or kernel

Defensive patterns

Strategy: retry

Prevention

Retry after flow stop to clear half-spawned state
Check loopback connection-rate/conntrack limits in containers if it recurs
Ensure the parent stays alive across both child connects (check its crash logs)

When it happens

Trigger: Parent dies in the window between the child's first and second connect; connection-rate limiting or ephemeral port exhaustion on loopback; sandbox policies permitting one connection but refusing rapid follow-ups.

Common situations: Parent crash during spawn under memory pressure; container/sandbox network limits; CI runners with aggressive conntrack recycling; supervisors tearing down the process tree mid-handshake.

Related errors

AI-assisted analysis of facebook/flow@f88ac94bcf (2026-08-20). Data as JSON: /api/errors/e6899112272da4da. Report an issue: GitHub.