Pagination for preview endpoints
I have some code like below but it appears to be dropping the Accept header for the preview of projects endpoint when trying to paginate. Is there some other way that I should be running configure to make that work?
$cardsApi = $githubClient->api('repo')->projects()->columns()->cards()->configure();
$paginator = new Github\ResultPager($githubClient);
$parameters = [$columnId];
$cards = $paginator->fetchAll($cardsApi, 'all', $parameters);
Anyone else seeing the same problem or know of a work around? Did this project get abandoned?
@acrobat ?
Hey. It is not abandoned. I read most of the issues and PRs and I know @acrobat is doing a great job being more active then me.
I've done some reading. I cannot see why it drops the Accept header. Could you debug the AcceptTrait::get and also see what is happening in the AcceptTrait::mergeHeaders function?
@bobeagan Sorry for the late reply! It would be indeed usefull if you could do some debugging in the AcceptTrait.
After that we can look further into the issue or create some reproducer. Thanks!
I have exactly the same problem with this snippet:
$search = $client->api('search');
$paginator = new Github\ResultPager($client);
$commits = $paginator->fetchAll($search, 'commits', ['author:' . $username]);
What results in:
PHP Fatal error: Uncaught Github\Exception\RuntimeException:
If you would like to help us test the Commit Search during its preview period, you must specify a custom media type in the 'Accept' header. Please see the docs for full details.
in /home/aaron/----/-----/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php:87
For a very quick workaround, you may use this:
$builder = new Builder();
$builder->addHeaderValue('Accept', sprintf('application/vnd.github.cloak-preview+json'));
$client = new Client($builder);
$search = $client->api('search');
$paginator = new Github\ResultPager($client);
$commits = $paginator->fetchAll($search, 'commits', ['author:' . $username]);
And it works without any issues.
^^ @bobeagan
It works perfect! Thank you!
Thanks @AronNovak ! I'm just getting back from vacation and catching up on things and was pleasantly surprised to find your workaround.
What's the status here? Do we need a fix in the library itself?
I believe so but I haven't had a chance to drill into specifically where the loss of the header value is occurring.
@GrahamCampbell do you know if this is fixed by the work that you did in #907 or perhaps by the change that you are planning for removing configure()?
The changes in that PR are unrelated. ;)