Stream doesn't get SHUTDOWN_COMPLETE

[nibanks]

Discussed in #2047

^{Originally posted by ManickaP October 5, 2021}
Client finished sending and gets SEND_SHUTDOWN_COMPLETE, then it calls ABORT_READ, and GRACEFUL StreamShutdown, yet it never receives SHUTDOWN_COMPLETE (until the connection gets closed minutes later).

On the server side, the stream shutdowns properly (receiving SHUTDOWN_COMPLETE) and destroys itself.

Attaching msquic.log extract.

And here's the sequence of shutdown calls from the client logs:

21:05:04.4342388[Info] thisOrContextObject: State#21233793, memberName: StartShutdown, message: [strm][0x7F37440A3120] Stream StartShutdown flags=ABORT_RECEIVE error=268
21:05:04.4342554[Info] thisOrContextObject: State#21233793, memberName: StartShutdown, message: [strm][0x7F37440A3120] Stream StartShutdown flags=GRACEFUL error=0
21:05:04.4342595[Info] thisOrContextObject: State#21233793, memberName: StartShutdown, message: [strm][0x7F37440A3120] Stream StartShutdown flags=ABORT_RECEIVE error=4294967295

Are we doing something wrong?

Converting to an issue since it's a real bug.

[nibanks]

So the problem is that an endpoint that sends a STOP_SENDING (i.e. aborts a receive) needs to handle the case where the peer never sends a RESET_STREAM and instead relies on the FIN. The code mostly handled this already, but there is a case where it does not.

The fix is to update the stream receive logic to not simply ignore all STREAM frames after abort. Instead, it must look for FINs and essentially treat them as a reset.