PHP SDK reports truncated errors when it doesn't have to (and how to fix it)

Shotstack API
1

When the PHP SDK throws an error, such as a ValidationError, it’s unclear what the error is because it’s truncated (thanks to Guzzle’s stupid default behavior). This renders error reporting virtually useless and makes solving the problem far more time-consuming than necessary.

However, it’s easy to fix and I’m not sure why it hasn’t been fixed since you definitely know about it. Since Guzzle’s documentation is terribly incomplete and inadequate (unlike your own—so a sincere thank you for that), I’d like to think you just didn’t want to dig through the Guzzle source code for an answer. Since I’m bad at asking for help until I’ve exhausted everything I can think of doing on my own, I did that and fixed it myself. That being said, it would be great if you updated the SDK to report the full error since it’s easy and we know this isn’t just a one-off issue for me.

So, here’s the problem. Let’s use the postRenderWithHttpInfo() function (in Api/EditApi.php) as the example. When the request fails and you report the error, you currently do it like this:

$e->getResponse()->getBody()

Instead, it should look like this:

$e->getResponse()->getBody()->getContents()

Anytime an error is returned via $e->getResponse()->getBody() it should have ->getContents() added on to ensure we actually get the error and not the (mostly) irrelevant portion of the error data that’s returned by the API. A simple find-and-replace should be able to take care of this in a few minutes.

2

Thank you! I’ve passed this along to be investigated. If as simple as you say we’ll look at fixing this ASAP.

3

Thanks for reporting this issue. The SDK’s are generated using the OpenAPI Generator project. That means if we update the code in our repo, it will get overwritten the next time we generate new code when we change the SDK.

You can see here in the project where this code is generated:

There’s 3 options we have here:

  • Update the OpenAPI project, submit a pull request and try to convince them to accept it.
  • We can create our own mustache template and use that but then we need to maintain that and try to keep it in sync with changes from the OpenAPI project.
  • We directly modify our code base each time after we update it, but that could lead to us forgetting to update it/human error.

Option 1 is the ideal solution so we can look at submitting a PR (unless you want to @adachis :wink:). The other two are less than ideal so we should try option 1 first.

4

I did some more digging in to the code. It seems that this is by design, but the demos are set up incorrectly.

The correct way to be handling the errors is like this:

try {
    $response = $client->postRender($edit)->getResponse();
} catch (ApiException $e) {
    die('Request failed: ' . $e->getResponseBody());
}

Instead of this:

try {
    $response = $client->postRender($edit)->getResponse();
} catch (Exception $e) {
    die('Request failed: ' . $e->getMessage());
}

Notice that we want to catch an ApiException, not a regular Exception. ApiException has a getResponseBody() with the full message.

The message is actually truncated by Guzzle. The OpenAPI generator then sends the message and the full body to the custom exception. What you are seeing is the value for getMessage. The new way shown will give you the full body.

Will endeavor to get that updated in the demos.

5

Playing around with it a bit more, depending on the type of error you get, getMessage provides more details. Perhaps the best solution is to echo both getMessage and getResponseBody. Or customise it to your needs.

6

Demos updated: PHP Examples (GitHub)