Improve handling of Rite Aid API errors

[Mr0grog]

Today we logged an API error from Rite Aid, but the error message was just “200 OK,” which is not very helpful: https://sentry.io/organizations/usdr/issues/2940100159

Luckily, more info was buried in the details object, which still go surfaced on Sentry:

{
  details: {
    body: {
      Data: null,
      Status: 'ERROR',
      ErrCde: '400',
      ErrMsg: 'Captcha validation failed. Please retry or contact system administrator',
      ErrMsgDtl: null
    }
  }
}

The RiteAidXhrError class should have given us a nicer message, but the message did not get set correctly for some reason.

univaf/loader/src/sources/riteaid/scraper.js

Lines 53 to 58 in 90b6441

	class RiteAidXhrError extends HttpApiError {
	parse(response) {
	super.parse(response);
	this.message = `${this.details.Status} ${this.details.ErrCde}: ${this.details.ErrMsg}`;
	}
	}

[Mr0grog]

Looks like the call to super.parse(response) probably threw an error getting details.error.message:

univaf/loader/src/exceptions.js

Lines 15 to 28 in 90b6441

	/**
	* Parse an HTTP response for error information and set relevant properties
	* on the error instance. This should be overridden by subclasses to handle
	* different error formats.
	*
	* It's safe for this to raise an exception (it will be handled and a more
	* generic error message will be set).
	*
	* @param {http.IncomingMessage} response An HTTP response with error info.
	*/
	parse(response) {
	this.details = JSON.parse(response.body);
	this.message = this.details.error.message;
	}

…So maybe RiteAidXhrError should just call JSON.parse() instead of super? Otherwise the superclass’s parse method should be written to be less failure-prone.

[Mr0grog]

We should probably also be re-using this error class in the Rite Aid API.