fix: avoid finishing write futures while stream is being closed

[diegomrsantos]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.77%. Comparing base (e9b4561) to head (9c1d879).
Report is 1 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1032      +/-   ##
============================================
+ Coverage     82.75%   82.77%   +0.02%     
============================================
  Files            91       91              
  Lines         15616    15620       +4     
============================================
+ Hits          12923    12930       +7     
+ Misses         2693     2690       -3     

Files	Coverage Δ
libp2p/muxers/mplex/lpchannel.nim	83.87% <100.00%> (+2.00%)	⬆️

[diegomrsantos]

Does anyone know why it was asyncSpawn here?

[arnetheduck]

the reset message is advisory - basically, it's a best-effort message that is sent in the hopes it will arrive and should therefore (in theory) not be allowed to block resetting the stream.

There's a bit of a terminology gap in libp2p as well - closing and resetting are used somewhat interchangeably.

If we take close to mean what it does in BSD sockets, it's an operation that cannot fail / always succeeds - it can return an error but even if it does, the socket is considered closed afterwards.

In libp2p, close means more or less what shutdown means in bsd and reset is the "irrevokable close now" function - it's important that such a function doesn't get "stuck".

I'm not sure what the consequences of waiting here would be tbh, it deserves some thought and lots of testing.

[diegomrsantos]

Could you please point out where it says it's a best-effort message? It doesn't seem like that here https://github.com/libp2p/specs/blob/master/mplex/README.md#resetting-a-stream.

[arnetheduck]

This should generally only be used on error;

the nature of the message is such that it is used when the stream is in an inconsistent state, ie when there is an error - because the stream is inconsistent, you also cannot guarantee that the message will be received by the other end and therefore you cannot rely on there being an answer to the message (it can get lost either locally, on the way to the other peer or the other peer may decide to not reply and if the other client is not reading the stream, it may get "blocked" forever).

[diegomrsantos]

We expect a close msg when closing or resetting here https://github.com/status-im/nim-libp2p/blob/242f516b5bd616873d70221fddbbcdb29f569153/libp2p/muxers/mplex/lpchannel.nim#L191.

We also change the stream state to reset at the beginning independently of what happens next https://github.com/status-im/nim-libp2p/blob/242f516b5bd616873d70221fddbbcdb29f569153/libp2p/muxers/mplex/lpchannel.nim#L104.

[diegomrsantos]

you cannot rely on there being an answer to the message

I don't think we expect any answer, do we?

[arnetheduck]

from the point of view of await, finishing the future is an answer - we don't expect an explicit message as answer, but from a buffer perspective, the future will not be finished until it has been given to the OS and the OS might not accept it until the other side sends an ACK confirming the receipt of earlier queued-up bytes.

[diegomrsantos]

Ok, I reverted the change. I think it's unrelated to the PR anyway.