Fix using auto_paging_iter() with expand: [...]
#1434
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
When you called
auto_paging_iter()on a list that you fetched withexpand, the server would give a 400 error. Ultimately, this was caused by the SDK making a malformed request with similar-but-differentexpandvalues.When you turn a response into a
StripeObject, we store the request url that created that response. That url includes any query params. So, given this code:hits the url:
/v1/invoices/upcoming/lines?customer=cus_ROQYYBI1BraV53&expand%5B%5D=data.price.productIn addition to the URL, Python's
StripeObjectalso stores theparamsused to create the object. On subsequent requests with the same object (e.g. when paging through a list) the SDK adds the original params to paging related ones (such asstarting_after) to the original url to make the request.Because the server returned the params and Python still has the params, we end up with duplicates in the url:
https://api.stripe.com/v1/invoices/upcoming/lines?customer=cus_ROQYYBI1BraV53&expand%5B%5D=data.price.product&limit=3&customer=cus_ROQYYBI1BraV53&expand[0]=data.price.product&starting_after=il_tmp_1QVdh7JoUivz182DmwLpUU1yNot only is
customerduplicated, there's bothexpand[]andexpand[0]keys. The latter is what's causing the issue. Clients can sendexpand[0]=a&expand[1]=borexpand[]=a&expand[]=b, but can't mix.The server sends
extend[]in itsurlresponse and python adds indexes, so the clobbering was the root of the issue.To fix, I parsed out the existing query params from a url and merged them with
params, which avoids duplicates. I also mergedexpandvalues just in case someone is expanding something new on thenext_page()call that wasn't expanded originally.This approach is a little kludgy, but does work and fix the bug. I'm open to other suggestions though!
What
GETorDELETErequest with additional params, deduplicate params.Testing
fixes RUN_DEVSDK-1427