Does a task-cancel interrupt a TcpStream read await?

[h1771t]

I create a task with something like:

t = ex.spawn(do_tcp_send(payload))

But later I need to cancel the task, so I do:

t.cancel().await;

I expect that the task cancel should immediately close any TcpStream in the task? But that's not the behaviour I seem to get.

Inside the task I'm doing:

smol::net::TcpStream::connect(SERVER).await
stream.write_all(&payload.into_bytes()).await
stream.read(&mut resp).await;

I mostly cancel the task waiting for the stream read. The cancel().await returns a None so the task is not completing (which is fine), but I'm not sure the tcp connection is being closed?
On the server side if I sleep the thread after reading the request, then write a response, I'm expecting the write response to fail since the client task was cancelled? It doesn't fail, so I'm suspecting the task cancel is not closing the tcp connection.

Any advice or suggestions would be much appreciated, thanks.

[nanoqsh]

I tried to reproduce the error. The server doesn't see the closed connection when it tries to write something to stream. But it does see it when it tries to read something. After reading (which returns Ok(0) as expected) when it tries to write something again, the server sees the Broken pipe error.

This behavior is inherited from the std::net::TcpStream implementation.
I found an issue related to this rust-lang/rust#93992

[h1771t]

Noted thank you for the info and the link. I was able to work around my issue because I had control of both client and server.
I worked around my issue by having the task take a channel and listen for a cancel message on the channel, and at the same time after writing data to the tcp stream, I used stream.try_read to check for a response. If a cancel message comes on the channel before the stream is ready to read, I wrote a "close" payload to the server. On the server side while waiting for other work to get done, it would try read from the client every so often, if it read a "close" payload, I'd make the server close the tcp connection.
This seems to work for me, probably not ideal but works around my issue for me.

[notgull]

t.cancel().await;

When the cancel() future is called, the task is polled one last time before it's dropped.

[h1771t]

So when I was having the issue, my task was sitting on a tcp stream read await, the code that made the task called cancel().await and it did return from the await, so that led me to assume the task is successfully cancelled and the tcp stream in the task must have been closed, but that turns out not to be the case. The task is cancelled but the tcp stream lingered. The link that @nanoqsh posted explains why it lingers I guess. In my case I needed the tcp stream to be torn down on task cancel. As noted above, I worked around it by sending the server a signal payload to shutdown the stream server side. The workaround suffices for me.