Response returned with status: INVALID_REQUEST

[jrean]

Hi,

    $googlePlaces = new PlacesApi('xxx');

    $collection = collect();

    $response = $googlePlaces->textSearch('xxx', [
        'type' => 'xxx'
    ]);
    $collection->push($response);

    $response = $googlePlaces->textSearch('xxx', [
        'pagetoken' => $response->get('next_page_token'),
    ]);
    $collection->push($response);

    dd($collection);

All returns:

SKAgarwal \ GoogleApi \ Exceptions \ GooglePlacesApiException
Response returned with status: INVALID_REQUEST

First query works perfectly and has a next_page_token. As long as I try the second query I got the error.

Can you please help?

Best,

J.

[mallardduck]

Dealing with the same issue here - seems that this feature isn't implemented by the library. ~The reason it's failing is that pagination requests only require the pagetoken set based on the next_page_token and the key for authentication.~

Edit: Details on this feature of the place API found here: https://developers.google.com/places/web-service/search#PlaceSearchPaging

EDIT 2: After further testing this what I shared here is not correct. The issue is not related to extra query parameters - Google's API actually just ignores the extras like you may expect. Leaving this intact but striking out the parts that are not accurate.

[mallardduck]

@SachinAgarwal1337 So it's pretty weird - I thought I could whip up a PR to add this feature, but something is going on. Basically I've been able to make the library support the feature however I'm still getting the "INVALID_REQUEST" status back.

Interestingly though when I enable debug mode for Guzzle the raw curl request looks valid. Not just that, but I can even take the text string from the debug output and it will work correctly in browser. If it weren't for using debug mode I'd be sure that I was still doing something super wrong. However, because the request URL works outside of the PHP script I know the URL being generated isn't the issue.

[mallardduck]

@jrean & @SachinAgarwal1337: Good News!

The issue is related to how the pagination works. Google's API documents state:

There is a short delay between when a next_page_token is issued, and when it will become valid. Requesting the next page before it is available will return an INVALID_REQUEST response. Retrying the request with the same next_page_token will return the next page of results.

As such, adding a 2 second delay to the subsequent page requests fixes this issue. From my testing a 1 second delay was not enough to get around this, so 2 seconds is what I landed on. Because this is a timing related concern dictated by: a) google and b) how your code works - I don't think this should be 'fixed'. As not all projects will use the library in the same way, adding the delay in the library wouldn't always be necessary - therefor would slow down usage that doesn't need the delay.

For instance, with my project I've structured it so that I would collect all the results and then process and save them. However I am confident that if I changed my strategy to process the first page results, save them and THEN get the second page then the sleep wouldn't be necessary.

[SachinAgarwal1337]

@mallardduck Thank you so much for figuring it out. And as you mentioned, this doesn't look it needs fixing. I will be closing the issue the.

[jrean]

I confirm @mallardduck is the right patch to go. I ended up using a sleep() of 2 seconds. 1 second not being enough.

@SachinAgarwal1337 maybe you could update the documentation to mention about this.

[greg0x46]

@mallardduck thanks, you saved my brain.

[zxu10]

Very helpful!!