On Thu, Aug 10, 2023, at 21:56, Nick Banks wrote: > While thinking of this and looking at our implementation, generally our > stack is fine, except for a possible race condition when we have a > stream queued up ready to send, but happen to process a packet for it > first. In the reset case, instead of sending out the stream frame, > we'll ack the reset and clean up our local (receive) state. Another > interesting variant of this would be if the peer sent STOP_SENDING on a > local unidirectional stream before we got a chance to send out anything > for it. In this case, we'd clean up all our state and ACK the packet, > send a RESET_STREAM and be done with it.
That's probably also true for STREAM frames, suggesting that the MUST-level requirement there might need some caveat. > In all these cases, while the peer shouldn't have done it, I believe the end > result is that we're still in sync. Agreed. I am not concerned about these cases. What you are doing is likely what others will have done also. That is, the state change happens when you decide to create the stream, not when the frames are sent. Some guidance roughly along those lines would probably help people to understand that.
