Sort service errors into the proper subclass

[ptpaterson]

Ticket(s): FE-5040

Problem

HTTPStreamClient implementations need to throw service errors if the initial response is a non-200. The logic to convert QueryFailure responses to the appropriate sub type is currently a private method on the Client class.

The StreamClient also needs to throw the appropriate service error class when a type=error event is received.

Solution

Move the Client.#getServiceError method to the errors module so it can be reused. Use it to throw the appropriate error if a type=error event is received or if the initial response is a non-200.

There is no http status code associated with streaming error events, so we should update error handling to rely first on the error code, then fallback to the base ServiceError if the error code is not matched.

Out of scope

N/A

Testing

Updated tests to check that the appropriate errors are thrown.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[cleve-fauna]

@ptpaterson you've got some tests failing.

[ptpaterson]

It's unrelated to the streaming tests. Looks like a check for client-timeout is being flaky.

[cleve-fauna]

It's unrelated to the streaming tests. Looks like a check for client-timeout is being flaky.

Can you try to deflake it?

[ptpaterson]

Error classes have been updated.

Fixes:

• invalid_query is the only real QueryCheckError code

Streaming changes

• FetchClient and NodeHTTP2Client return NetworkErrors when problems are encountered after the stream is connected.

New breaking changes compared to v1.3.1

• The httpStatus field for ServiceErrors is now optional
• Added a ConstraintFailureError class and broke that out from QueryRuntimeError
• Merged the ServiceTimeoutError class into the QueryTimeoutError class. They share the same time_out code.

[ptpaterson]

Chose to make httpStatus optional. This seemed more consistent with encouraging folks to not rely on the HTTP status code than the sentinel -1.

However, it will break any existing Typescript code that reads error.httpStatus without guarding against null.

[ptpaterson]

I merged the ServiceTimeoutError class into QueryTimeoutError. We talk about "client timeouts" vs "query timeouts" so I think that's the appropriate name, and QueryTimeoutError already had optional stats field defined.