Should we remove INTERNAL_ERROR?

[afrind]

See this comment: #1159 (comment)

INTERNAL_ERROR

I'd like to remove this error. It it completely unspecified what the device receiving this error does when it gets it.

[afrind]

Specs that have this error:

QUIC: https://datatracker.ietf.org/doc/html/rfc9000#section-20.1
HTTP/2: https://www.rfc-editor.org/rfc/rfc9113.html#name-error-codes
HTTP/3: https://datatracker.ietf.org/doc/html/rfc9114#name-http-3-error-codes

AI also thinks XMPP and even DNS (ServFail) have similar errors.

Endpoints will fail for reasons not listed in the spec. Trying to enumerate them all is not possible, so you have to have a catch all. If you don't, then endpoints will either 1) make their own, non-standard catch all code or 2) use a defined code incorrectly, both of which are worse outcomes.

[LPardue]

The comment #1159 (comment) seems to have the presumption that endpoints do anything with regards to receiving specific values of error codes.

That is a pattern we don't follow in QUIC or HTTP/3.

I agree with Alan here that there is valueing i signalling that a failure happened for some internal non-protocol reason, precisely because the protocol may have no way to react to that other than give up and fall the problem to humans to go investigate out of band.

[vasilvv]

As an implementer, Internal Error is just the default error I sent when something wrong went on my side (disk I/O error or something).

It it completely unspecified what the device receiving this error does when it gets it.

The answer for 95% of error scenarios is "fail the operation and optionally propagate the error message to the end user".

[fluffy]

The issue is, at this point the everything is in a pretty unknown state of what can happen next. If sending an internal error also always closes the connection at the same time, then this makes sense. But if it is something like a disk read on a fetch failed and the user should try again in 2 seconds the the error should be fetch failed with information to retry after 2 seconds.

[ianswett]

I've found this useful in QUIC, since it's a way to say "Something went wrong, it's not one of the other standard error types, and it's probably my fault."

[afrind]

The issue is, at this point the everything is in a pretty unknown state of what can happen next. If sending an internal error also always closes the connection at the same time, then this makes sense. But if it is something like a disk read on a fetch failed and the user should try again in 2 seconds the the error should be fetch failed with information to retry after 2 seconds.

There's nowhere we currently recommend ending something with INTERNAL_ERROR. I generally agree that if you want to enable some specific behavior by the receiver of the error (eg retry this), we should define specific error codes for that. Maybe we could split INTERNAL_ERROR into retryable and non-retryable variants? I'll note that HTTP has structure semantics (Retry-After) that could be useful.

[fluffy]

What deadline is this past ?

[afrind]

What deadline is this past ?

Since this text has existed since a very early draft, it was included in the draft-11 consensus call that closed on June 2: https://mailarchive.ietf.org/arch/msg/moq/tIeLopmqQeznB8DhyTjM4DTvVE0/.

Note, we still plan to discuss it.

[ianswett]

In Toronto:
It's believed that this will be solved by @martinduke work to document error codes and what to do when get one. See issue #1175