FramedWrite on UnixSockets do not flush - MacOS only

[Firstyear]

I have a unix stream socket with actix = "0.9" on MacOS. When it receives a message and writes a response to the FramedWrite, the content is not flushed until the socket is closed.

This can be shown with netcat quite easily. I am attaching a sample program and request.

What happens is the request is sent:

nc -Uv /tmp/uds_flush.sock < sshkey_req.cbor

The server sees it, and then attempts to respond

Running ...
Processing -> Ok(SshKey("william"))
Attempting to send response -> [161, 100, 69, 99, 104, 111, 103, 119, 105, 108, 108, 105, 97, 109] ...

Net cat then shuts down due to no response.

With a rust based client that blocks, the client blocks until the server is ctrl-ced - then the server finally calls flush and the IO is sent.

This can not be reproduced on linux - on linux it appears to behave correctly. It only seems to affect flushing on MacOS.

actix_uds_repro.zip

[Firstyear]

Setting up a customised version of actix with the addition of a manual flush on FramedWrite so that the caller can do:

framed.write(data);
framed.flush();

The actix framedwrite flush is based on the content of drop:

    pub fn flush(&mut self) {
        println!("actix flush occuring");
        let mut async_writer = self.inner.1.borrow_mut();
        let inner = self.inner.0.borrow_mut();
        if !inner.buffer.is_empty() {
            // Results must be ignored during drop, as the errors cannot be handled meaningfully
            let _ = async_writer.write(&inner.buffer);
        }
        let _ = async_writer.flush();
    }

On the server this shows the correct "actix flush occuring" message, yet the client still is not sent the data. Again, it is only when the socket is closed is the flush really occuring.

Could this be a deeper problem with unix sockets in tokio?