Helping developer to debug bad API calls

[matks]

Hi !

I report a very weird bug 😅 ... very weird because I use some code 1 month ago, everything is great 👍 and now same code fails.

Very simple usecase: create new file into repository. I used my fork of php-github-api as example.

<?php

require_once __DIR__ . '/vendor/autoload.php';

$client = new \Github\Client();
$token = 'XXX';
$client->authenticate($token, null, Github\Client::AUTH_HTTP_TOKEN);

$committer = array('name' => 'matks', 'email' => 'myemail@gmail.com');

$fileInfo = $client->api('repo')->contents()
    ->create('matks', 'php-github-api', 'test.md', 'a', 'test', 'master', $committer);

Code worked some months ago, I want to reuse it, now it fails with following error:

PHP Fatal error:  Uncaught Github\Exception\ErrorException: Problems parsing JSON in /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php:51
Stack trace:
#0 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/php-http/httplug/src/Promise/HttpFulfilledPromise.php(34): Github\HttpClient\Plugin\GithubExceptionThrower->Github\HttpClient\Plugin\{closure}(Object(GuzzleHttp\Psr7\Response))
#1 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php(106): Http\Client\Promise\HttpFulfilledPromise->then(Object(Closure))
#2 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/php-http/client-common/src/Plugin/VersionBridgePlugin.php(19): Github\HttpClient\Plugin\GithubExceptionThrower->doHandleRequest(Object(GuzzleHttp\Psr7\Request), Object(Closure), Object(Closure))
#3 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/php-http/client-common/src/ in /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php on line 51

Fatal error: Uncaught Github\Exception\ErrorException: Problems parsing JSON in /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php:51
Stack trace:
#0 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/php-http/httplug/src/Promise/HttpFulfilledPromise.php(34): Github\HttpClient\Plugin\GithubExceptionThrower->Github\HttpClient\Plugin\{closure}(Object(GuzzleHttp\Psr7\Response))
#1 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php(106): Http\Client\Promise\HttpFulfilledPromise->then(Object(Closure))
#2 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/php-http/client-common/src/Plugin/VersionBridgePlugin.php(19): Github\HttpClient\Plugin\GithubExceptionThrower->doHandleRequest(Object(GuzzleHttp\Psr7\Request), Object(Closure), Object(Closure))
#3 /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/php-http/client-common/src/ in /Users/mFerment/www/perso/prestashop-repos-bulk-editor/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php on line 51

I tried to debug this "Problems parsing JSON" and found different people having it, but nothing similar to my very simple usecase. The things I found were mostly people building their requests to GitHub API manually with cURL or Postman and they had to require some specific http header or pass JSON in body or in param to make it work. Which is what php-github-api should do, right 😅

Because I have "the code worked 1 month ago and now it fails" I guess 2 possibilities:

• github API was updated and it's a bug
• php-github-api got a new version, I upgraded it through Composer and I found a bug

[matks]

Tested with php-github-api v2.12.1 and v2.14.0 : same behavior

[matks]

Nevermind ... found the issue

So, just for the record: I stored my github token into a TXT file protected by .gitignore but whenever I would save it with my IDE, my IDE would "kindly" add a blank trailing line 🤣 so my token would get an extra \r\n and be invalid.

The funny thing is that some other calls worked 🤔 like creating a fork, checking if a file exists, fetching branches ; does that mean these other calls do not need to be authorized / authenticated ?

So I stopped using my IDE and use vim instead 😛 and now it works

[matks]

Reopening the issue because in fact this might be interesting (feel free to close issue if it's out of scope)

Suggestions for improvements:

• error was very unhelpful for debugging because it's hard to trace which call to API Client fired the exception
• error was very unhelpful for debugging because the error message was very vague ... but I guess it comes from GitHub so nothing easy can be done right ?
• idea: when user authenticate with a wrong token $client->authenticate do some checking to tell him whether token is valid ; because I was able to call multiple API endpoints (see below) with a bad token without being told it was invalid (which is why I searched the issue for hours)

Here are the calls I could do with a bad token:

            $repo = $this->client->api('repo')->show($githubUsernameForker, $repositoryName);
            $fork = $this->client->api('repo')->forks()->create($githubUsernameOriginal, $repositoryName);
            $references = $this->client->api('gitData')->references()->branches('prestashop', $repositoryName);
            $pullRequests = $this->client->api('pull_request')->all($username, $repositoryName, ['state' => 'all']);
            $references = $this->client->api('gitData')->references()->branches($username, $repositoryName);

[acrobat]

@matks what do you actually mean with "when user authenticate with a wrong token "? What is a wrong token?

[matks]

@matks what do you actually mean with "when user authenticate with a wrong token "? What is a wrong token?

Very accurate question because you are right: there is multiple usecases 😄

Completely bad token

$client = new \Github\Client();
$token = 'aaa';
$client->authenticate($token, null, Github\Client::AUTH_HTTP_TOKEN);

$repo = $client->api('repo')->show('matks', 'prestashop');

I get Fatal error: Uncaught Github\Exception\RuntimeException: Bad credentials => good ✅

Valid token

$client = new \Github\Client();
$token = 'A_VALID_TOKEN';
$client->authenticate($token, null, Github\Client::AUTH_HTTP_TOKEN);

$repo = $client->api('repo')->show('matks', 'prestashop');

$committer = array('name' => 'matks', 'email' => 'myemail@gmail.com');

$fileInfo = $client->api('repo')->contents()
    ->create('matks', 'php-github-api', 'aaa.md', 'a', 'test', 'master', $committer);

This works ✅

Token with trailing empty line

$client = new \Github\Client();
$token = 'A_VALID_TOKEN'.PHP_EOL; // <= look at this !
$client->authenticate($token, null, Github\Client::AUTH_HTTP_TOKEN);

$repo = $client->api('repo')->show('matks', 'prestashop');

$committer = array('name' => 'matks', 'email' => 'myemail@gmail.com');

$fileInfo = $client->api('repo')->contents()
    ->create('matks', 'php-github-api', 'aaa.md', 'a', 'test', 'master', $committer);

I get Fatal error: Uncaught Github\Exception\ErrorException: Problems parsing JSON => 🔴 for $client->api('repo')->contents() but the 1st API call $client->api('repo')->show('matks', 'prestashop'); worked without issue

So it looks like some API calls work fine if there is a trailing empty line at the end of the token while others fail with unhelpful error message 🤔

Which is my definition of "bad token" for the scope of this issue: valid token with trailing empty line

I guess it might come from how the data is being transferred over HTTP (in query or as GET parameter or as body ?)

Now that I see it, it looks like I am in an exotic usecase so it might not be worth it fixing it in the codebase.

[acrobat]

Github doesn't provide more info on what is exactly wrong. So the only thing what we could do is add the reasonPhrase based on the response code. So the error would be "Problems parsing JSON (Bad Request)", this way you have a bit more info that it's related to the request. Wdyt?

See #760

[matks]

Github doesn't provide more info on what is exactly wrong. So the only thing what we could do is add the reasonPhrase based on the response code. So the error would be "Problems parsing JSON (Bad Request)", this way you have a bit more info that it's related to the request. Wdyt?

See #760

It's a good improvement 👍