#mr_pablo
1 messages · Page 1 of 1 (latest)
I believe that's accurate as has_more maps to more data after that set, not before it
but if you load the first page, without endingBefore, has_more is true
Exactly, because there's a 2nd page
and there is still a second page when i view the first with endingBefore
it didn't disappear
I'm confused, can you provide req_xxx IDs and some JSON
I'm doing this through a proxy API, and tracking the has_more value in our logs. But I can provide a customer ID for you to look up the session list
I just quickly tested this, and its working as expected IMO
So you think that going from page 2 to 1, using the provided pagination params, has_more should be set to false ?
Yes, because:
Whether or not there are more elements available after this set. If false, this set comprises the end of the list.
https://stripe.com/docs/api/pagination#pagination-has_more
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
If page 2 is the last page, there are no more records
but I'm going from page 2, to page 1, setting endingBefore as the first ID in the page 2 list
So im talking about being on page 1
I started on page 1, has_more is true. I go to page 2, using startingAfter and the last ID on page 1. I'm now on page 2.
Taking the ID of the first item on page 2, I make a URL, using endingBefore and the ID, this is taking me back to page 1. I'm now on page 1, and has_more is false
Ok, thanks for clear reproduction steps! I can see that now too
I'm still unsure if that is expected or not though (pagination is confusing)
I'll file an issue with the team
TBH, the pagination on that endpoint is pretty poor, and this bug certainly doesn't help matters
Thanks for feedback. We will forward to the team