REST API does not throw HTTP error message/code

[haseebanwar]

When there is an HTTPError, the error object thrown does not contain any info about the error. For instance, creating a customer with an existing email like:

shopify.customer.create({
  first_name: 'John',
  last_name: 'Doe',
  email: 'alreadyexisting@email.com'
});

will throw the following error:

error HTTPError: Response code 422 (Unprocessable Entity) {
  name: 'HTTPError',
  code: undefined,
  timings: {
    start: 1614248835511,
    socket: 1614248835511,
    lookup: 1614248835691,
    connect: 1614248835728,
    secureConnect: 1614248835764,
    upload: 1614248835770,
    response: 1614248836439,
    end: 1614248836441,
    error: undefined,
    abort: undefined,
    phases: {
      wait: 0,
      dns: 180,
      tcp: 37,
      tls: 36,
      request: 6,
      firstByte: 669,
      download: 2,
      total: 930
    }
  }
}

The code is undefined, error is undefined. Any workaround to access the errors that Shopify Admin API actually returns. In this case, the errors are:

{
    "errors": {
        "email": [
            "has already been taken"
        ]
    }
}

[lpinca]

Use error.response.body. Where error is your error.

[haseebanwar]

@lpinca does the error object contains any code or name that tells if the error is from Shopify API i.e. error.name is ShopifyAdminError so I can check in the catch block if the error is from Shopify API. Like this:

try {
  const customer = await shopify.customer.get(customerId);

  const anotherAsync = await otherClient.get();
} catch(error) {
  if (error.name === 'ShopifyAdminError') {
    // do something
  } else {
    // do something else
  }
}

[lpinca]

@haseebanwar no, we just return the error from got (the HTTP client used by shopify-api-node) as is.

[lpinca]

I understand it is not clean, but in your example you could use two different try...catch, one for each await expression.

[haseebanwar]

@lpinca got it, thanks. Any plan of implementing such logic in the future?

[lpinca]

No plan at the moment. If it is requested by a consistent amount of users we might consider it.