ApiClient.callApi throws an unhandled TypeError (and never invokes the callback) when a request fails with no error.response (timeout, ECONNREFUSED, DNS failure, etc.)

Version: cybersource-rest-client@0.0.81 (axios ^1.15.2)

Location: src/ApiClient.js

Description:

In ApiClient.prototype.callApi, the axios error handler unconditionally dereferences error.response.data:

axios.request(axiosConfig).then(function(response) {
  ...
}).catch(function(error, response) {
  source.cancel('Stream ended.');
  MLEUtility.checkAndDecryptEncryptedResponse(error.response.data, _this.merchantConfig)
    .then(function(decryptedData) {
      ...
      callback(userError, null, response);
    })
    .catch(function(error) {
      ...
    });
});

Axios only populates error.response for a non-2XX HTTP reply. For any error where no HTTP response was ever received — a client-side timeout (ECONNABORTED), ECONNREFUSED, a DNS failure, or any other network-level error — error.response is undefined, so error.response.data throws a TypeError: Cannot read properties of undefined (reading 'data').

Example from axios documentation:

axios.get('/user/12345').catch(function (error) {
  if (error.response) {
    // The request was made and the server responded with a status code
    // that falls out of the range of 2xx
    console.log(error.response.data);
    console.log(error.response.status);
    console.log(error.response.headers);
  } else if (error.request) {
    // The request was made but no response was received
    // `error.request` is an instance of XMLHttpRequest in the browser and an instance of
    // http.ClientRequest in node.js
    console.log(error.request);
  } else {
    // Something happened in setting up the request that triggered an Error
    console.log('Error', error.message);
  }
  console.log(error.config);
});

Because this throw happens synchronously inside the .catch handler, and callApi never returns the axios.request(...).then(...).catch(...) chain (nor wraps this block in a try/catch), the resulting rejection is not caught anywhere in the SDK:

• The callback(error, data, response) passed in by the caller is never invoked — neither with an error nor with data.
• The rejection becomes an unhandled promise rejection in the consuming process. On modern Node (which terminates by default on unhandled rejections unless the app registers its own process.on('unhandledRejection', ...) handler), this can crash the whole process.

So the practical impact is: any transient network issue when calling the API (not an actual API error response, just a dropped connection or timeout) either hangs the caller's promise/callback forever, or crashes the host process — instead of surfacing as a normal error through callback.

Suggested fix:

Guard on error.response before touching .data, mirroring the existing branches for ECONNREFUSED/ERR_BAD_REQUEST/ETIMEDOUT immediately below:

}).catch(function(error) {
  source.cancel('Stream ended.');

  if (!error.response) {
    // no HTTP response received at all (timeout, ECONNREFUSED, DNS failure, ...)
    var userError = {};
    if (error.code && error.code == "ECONNREFUSED") {
      userError = _this.translateProxyIssue(error);
    } else if (error.code && error.code == "ETIMEDOUT") {
      userError = _this.translateProxyIssue(error);
    } else {
      userError = _this.translateError(error);
    }
    if (callback) {
      callback(userError, null, userError.response);
    }
    return;
  }

  MLEUtility.checkAndDecryptEncryptedResponse(error.response.data, _this.merchantConfig)
    .then(function(decryptedData) {
      ...

Happy to open a PR with this fix if that's useful.

Start in src/ApiClient.js around line 876 and inspect the axios rejection handler alongside the existing ECONNREFUSED, ERR_BAD_REQUEST, and ETIMEDOUT branches. Verify behavior for failures without error.response, including timeout, connection refusal, and DNS errors. Done means the callback receives the translated error and no unhandled TypeError or promise rejection occurs.