Cronvoy: map Envoy Mobile internal errors to Cronet internal errors

[carloseltuerto]

Cronet exposes 235 internal errors split in 9 categories. Cronet internal error codes are not guaranteed to be stable. However, some of those internal error codes are mapped to the public error code scheme, others are driving some business logic, and couples are used for tests only - having these properly mapped with Envoy Mobile internal error codes will likely avoid regressions. Following error codes should be considered:

• NAME_NOT_RESOLVED - mapped to public error code
• INTERNET_DISCONNECTED - mapped to public error code
• NETWORK_CHANGED - mapped to public error code
• TIMED_OUT - mapped to public error code
• CONNECTION_CLOSED - mapped to public error code
• CONNECTION_TIMED_OUT - mapped to public error code
• CONNECTION_REFUSED - mapped to public error code
• CONNECTION_RESET - mapped to public error code
• ADDRESS_UNREACHABLE - mapped to public error code
• QUIC_PROTOCOL_ERROR - mapped to public error code
• CONTENT_LENGTH_MISMATCH - testing
• HTTP2_PING_FAILED - business logic
• QUIC_HANDSHAKE_FAILED - business logic
• SSL_PINNED_KEY_NOT_IN_CERT_CHAIN - testing
• DISALLOWED_URL_SCHEME - testing

Envoy Mobile does expose an internal error code, but will likely require more work:

• It not always populated, for example, when Envoy Mobile attempts to connect to this URL, "http://127.0.0.1:319", the request does end up as an error, as expected (that socket is purposely invalid). But the error does not provide much details. The internal error code is 0: 'x-internal-error-code', '0', and the error message is an empty String.
• It does not provide the same error granularity.

[alyssawilk]

@DavidSchinazi when you're back, this feels like a space where I (who know Envoy errors) could collaborate with Renjie (who knows Chrome ones) to do a mapping of sorts?

[DavidSchinazi]

@alyssawilk that sounds great. Though in this case I'm surprised that Envoy treats a TCP RST as an internal error?

[alyssawilk]

I suspect that's an artifact of the old error pathways that @goaway has mentioned. Upstream reset should be communicated with the UpstreamRemoteReset flag is set and EarlyUpstreamReset/LateUpstreamReset details, which can be converted into the relevant Chrome error

[DavidSchinazi]

Is there an action item for Cronvoy to set that flag, or will Envoy Mobile do it by default?

[carloseltuerto]

Personally, I would expect Envoy Mobile to provide a fined grained error scheme. ERR_CONNECTION_REFUSED is not the only one here - there are 235 of them.

This is how chromium//net splits the error domain:

     0- 99 System related errors
   100-199 Connection related errors
   200-299 Certificate errors
   300-399 HTTP errors
   400-499 Cache errors
   500-599 Misc errors
   600-699 FTP errors
   700-799 Certificate manager errors
   800-899 DNS resolver errors

[carloseltuerto]

But there is somewhere a good news. It is understood that those internal errors are subject to changes, and performing business logic against those is "at your own risks". So we don't need to have the same 235 errors, that's for sure. On the other hand, I guess that for some of these errors, it would be damning if Cronvoy would not return the same error. Here, Envoy Mobile can have its own scheme, and Cronvoy will give them a Cronet "look".

[carloseltuerto]

More details were added to the description of the issue.