Error types are inaccurate

[knowlesc]

the GraphQLResponse type is defined like this:

However, if there's an internal node error, which we occasionally see ("Premature close"), the response looks like this:

{
      data: undefined,
      errors: [
        {
          name: "FetchError",
          message: "Invalid response body while trying to fetch https://app.useanvil.com/graphql: Premature close",
          code: "ERR_STREAM_PREMATURE_CLOSE",
          stack:
            "FetchError: Invalid response body while trying to fetch https://app.useanvil.com/graphql: Premature close",
        },
      ],
      statusCode: 200
    }

It would be great if we could rely on the error types to be able to safely parse errors.

Thank you!

[newhouse]

Hello @knowlesc and thanks for writing in!

I'm not an expert in TypeScript, but doesn't that error you're showing adhere to the type ResponseError type definition?

• message is the only key marked as required, and it is present, and is a string as specified.
• name is not required, but it is a string as specified.
• no other explicitly defined keys are present, and so are also not violated.
• there are no required keys missing.
• code and stack would fall into the "catch-all" of [key: string]: any;, would they not?

Am I wrong about this or was there something else you were expecting? It's hard to anticipate all the myriad errors that we may encounter, so I'm not sure that there's a realistic way to code for all of them. Let me know your thoughts, please.

[knowlesc]

Hi @newhouse - thanks for the quick response.

This behaviour is technically accurate, however it doesn't make it clear which keys will be included. An any in TypeScript doesn't really provide any info. Looking at the code, I can see a function to normalize node errors here: https://github.com/anvilco/node-anvil/blob/main/src/errors.js#L36-L47

When that executes, we have a set of clearly defined error keys (name, message, code, cause, stack). The response error type would be clearer if it was something like:

 * @property {Array<ResponseError | NodeError>} [errors]

where NodeError was defined as

/** @typedef {{
  message: string,
  code: number,
  cause: string,
  stack: string,
  name: string,
}} NodeError */

At least this way, consumers can understand that errors may come back in that format, and build their error handlers to specifically handle those types of errors, without having to dig into the library code.

Hopefully my description makes sense - let me know if you have any questions.

[newhouse]

OK, that sounds good. I added this in 3.3.1. @knowlesc can you pull that down and try it?

[newhouse]

Going to close this for now.