QuicTransportBase.stop() in 'failed' state about webtransport HOT 2 CLOSED

User's code (or understanding) should be geared towards the higher level abstraction.
I would recommend sticking with a disposable pattern where the user:

1. creates object
2. uses object
3. disposes (closes) object

regardless of what transpires, the user should still be disposing of the object when it is done.
The current details that a failed connection is unrecoverable and optimization around freeing resources when that happens, should not impact this pattern.
In this case, i would say close() should transition the object state from failed to closed.

from webtransport.

@amithilbuch Currently the spec doesn't say anything about freeing resources.

Changing the state to "closed" sounds good to me. If the transport is in the "failed" state it can't send any more CONNECTION_CLOSE frames, so I think these steps should be skipped in this case:

An endpoint that receives a CONNECTION_CLOSE frame
MAY send a single packet containing a CONNECTION_CLOSE frame before
entering the draining state, using a CONNECTION_CLOSE frame and a
NO_ERROR code if appropriate. An endpoint MUST NOT send further
packets, which could result in a constant exchange of
CONNECTION_CLOSE frames until the closing period on either peer
ended.

https://tools.ietf.org/html/draft-ietf-quic-transport-19#section-10.3

from webtransport.