Client.php not allowing JSON error returns from the AvaTax API about avatax-rest-v2-php-sdk HOT 11 CLOSED

@caleywoods Passing $guzzleParams['http_errors'] = false; to AvaTaxCient constructor solves this problem. example:

$guzzleParams['http_errors'] = FALSE;
$client = new Avalara\AvaTaxClient('My App', '1.0', 'development', 'sandbox', $guzzleParams);

from avatax-rest-v2-php-sdk.

You can use $client->withCatchExceptions(false);
To catch the error also

from avatax-rest-v2-php-sdk.

I tested my exact call with an online tool named Hurl.it and it looks like the API itself is doing a great job returning an HTTP 400 and the response as JSON. That can be seen in the screenshot below:

Once you step into the world of the Avalara PHP SDK / Guzzle however, this same request throws an exception as I mentioned in my first comment. I've managed to track down the cause of this.

According to the Guzzle Docs about Exceptions, HTTP level 400 response codes raise a GuzzleHttp\Exception\ClientException if the http_errors request option is set to true. "True" is the default setting for http_errors. I went into the src/Client.php file from Avalara and added:

$guzzleParams['http_errors'] = false;

To the restCall() method as soon as the function signature is done (making it the first line of the function). This results in Guzzle no longer raising an Exception and then stops causing the Client file to stop catching that Exception and returning error strings (via $e->getMessage()).

I am not sure that turning HTTP_ERRORS off is a great idea so I am stuck as far as having a real permanent solution. Turning them off certainly gives consumers of the API via the SDK a better experience with 4xx level errors but I did make a createTransaction API call using the $include param of 'ForceTimeout' to force Avalara to respond with a 504 Gateway Timeout and with the HTTP_ERRORS turned off, no exception or issue was raised by Guzzle and I received null when echoing out the result of a create() call from TransactionBuilder.

from avatax-rest-v2-php-sdk.

This is a really interesting comment - I'm not sure how this slipped past. I've asked our resident PHP experts @Spadbob and @nitinshirsat to help identify whether there's a good way to improve on this. Would love suggestions!

from avatax-rest-v2-php-sdk.

Hi @caleywoods

We've implemented request events http://guzzle3.readthedocs.io/http-client/request.html#events-emitted-from-a-request and in the event handler, we are setting standard error message and response code instead of using exception. Which help us keep API error messages and codes in sync. Meaning that on an error it'll return the response with the error code and message, so no need to catch and throw extra exceptions.

from avatax-rest-v2-php-sdk.

I am having the same problem. In case of 400 errors, Guzzle is retuning a truncated... string instead of error object with errors messages. To reproduce try this code, don't add any line items:

$tb->withAddress('ShipFrom', '123 Main Street', null, null, 'Irvine', 'CA', '92615', 'US')
->withAddress('ShipTo', '100 Ravine Lane', null, null, 'Bainbridge Island', 'WA', '98110', 'US');
$result = $tb->create();

from avatax-rest-v2-php-sdk.

@ted-spence-avalara / @han8909227

I see that the catchExceptions PR was pulled into master but I wasn't sure if master represented the current version of code available to those grabbing it via composer since I didn't see the changes listed in the most recent tag of 17.12.0-148.

I think @khaldoonmasud problem should be fixed with #61

from avatax-rest-v2-php-sdk.

@caleywoods Yes, we deploy/tag the master branch, meaning master is the same as the most recent tag 18.5.1.208 which is on composer as well. So PR #61 should be included in the current version.

Following @khaldoonmasud 's code, I was able to replicate the string formatted error message:
Client error: POST https:\/\/sandbox-rest.avatax.com\/api\/v2\/transactions\/create resulted in a 400 Bad Request response:\n{\"error\":{\"code\":\"MissingLine\",\"message\":\"Transactions must have at least one line.\",\"target\":\"HttpRequestHeaders\",\"deta (truncated...)\n

This might need some further investigations.

from avatax-rest-v2-php-sdk.

@khaldoonmasud yes that was the workaround I ended up going with as well when I encountered the problem. I have moved on to a different job so I cannot go back and update the version of the avalara software and do any further testing.

from avatax-rest-v2-php-sdk.

That fix is good for me.

try {
    // avalara request ...
    $response = $tb->createOrAdjust();
} catch (\GuzzleHttp\Exception\ClientException $e) {
    $error = $e->getResponse()->getBody()->getContents();
}

Example error response:

{
  "error":{
    "code":"ModelStateInvalid",
    "message":"The request body did not contain valid JSON.",
    "target":"HttpRequest",
    "details":[{
      "code":"JsonFormatError",
      "number":47,
      "message":"The request body did not contain valid JSON.",
      "description":"At line 1 position 758: Unexpected character encountered while parsing value: t. Path 'createTransactionModel.discount'",
      "faultCode":"Client",
      "helpLink":"http://developer.avalara.com/avatax/errors/JsonFormatError",
      "severity":"Error"
    }]
  }
}

from avatax-rest-v2-php-sdk.

This issue is fixed as part of #183. Please verify and revert if in case it is not resolved at your end.

from avatax-rest-v2-php-sdk.