WebTransportError.isInitiatedByClient

[yutakahirano]

I think it'd be benefitial to have this boolean attribute in WebTransportError.

The attribute returns whether the error comes from the client. This will allow the script author to distinguish whether the stream (or session? There is no way to abort a session/connection from the script I believe, though...) is aborted because of the abort request from the client, or some issues in the server or network.

I don't know which milestone is appropriate - On the one hand, this is a nice to have. On the other hand, we may want to check this attribute in cancelArgorithm and abortAlgorithm, and that will be an incompatible change and hence we may want to do that before in the initial release.

What do you think?

[vasilvv]

This would make sense, as we have similar boolean in our QUIC API. One thing I will note though is that it should be possible to communicate this information via errorSource field (or whatever we call it), so we have two approaches here to choose from.

[jan-ivar]

Meeting:

• Preference for enum
• Open to bikeshedding further. something = "client" | "server" ? initiator not the best since clients don't technically initiate errors, they just happen
• A nice to have

[jan-ivar]

(or session? There is no way to abort a session/connection from the script I believe, though...)

The script can call wt.close(closeInfo). But I don't think this spec should solve a script not knowing it did that.

I'm tempted to say the same about client stream errors from stream.abort(new WebTransportError({streamErrorCode})).