#dfabulich_api
wet belfryBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1367524995768647751
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
covert gazelle
wet belfryBOT
fair girder
Hi 👋
I'm stepping in as my colleague needs to go soon
I agree the error message is not very helpful here. However, can I ask why you are taking the manual pagination approach rather than our Node SDK's auto-pagination?
https://docs.stripe.com/api/pagination/auto?lang=node
odd shadow
I guess I can try that. I have a hunch it's going to fail in the same way.
Yup, it crashed in the same way.
In order to tell autoPagingEach when to stop, I had to add a { available_on: { gt: startTimestamp } } parameter. When I use that, it crashes right away before returning even a single page of results
await stripe.balanceTransactions.list({ available_on: { gt: startTimestamp } }).autoPagingEach(transaction => {
console.log({transaction});
})
We ran out of time while trying to count the objects you requested. To avoid this issue, omit include[]=total_count from your API request parameters.
req_D9k7XK0fT1XRjY
fair girder
Hmmm let me see if I can reproduce this behavior
And since you are not specifying a limit you should only be retrieving 10 balance transactions at a time.
Hmmmm.... you are on a VERY old API version. I'm not able to find the available_on parameter in any of our documentation. I wonder if we broke something something there.
Okay no, I was able to make basically the same request with the same API version and auto-paginate
fair girder
I've reached out to my colleagues to see if we can find anything else. I'm looking in the logs for exactly where this error is coming from but so far haven't found any smoking gun
odd shadow
I upgraded to a newer version of the Stripe JS package and switched to auto-pagination, and the error no longer appears.
fair girder
Can you share a newer request ID? I'm still really curious about why this was happening.
odd shadow
This seems like a pretty surprising way to workaround a 500 error, but, I guess it's working, soooo 🤷♂️
req_5SiVNqS0FkmYfb succeeded
that was a starting_after … here's an initiating request req_GrA7nDjOBIw72W
fair girder
Wow, you went from a 8.x version to 18.x. That's a big jump. But now you are even specifying limit=100 so you would expect this to be more likely to time out.
I think we probably just aren't handling something about the old API version correctly and instead returning an unhelpful 500 error
odd shadow
I had limit=100 prior to hitting this bug; I pulled limit=100 out in the hopes that it would help
So when upgrading worked, I put limit=100 back in
It's so weird, because it seems like there's nothing fundamentally different about the requests themselves.
The query parameters are the same. The endpoint is the same.
fair girder
Yeah, I'm talking with a colleague about it
It seems like this is due to the available_on parameter. We don't document this parameter because we discourage using it. It often results in these kinds of timeouts.
I recommend using the created parameter instead
I realize it doesn't do the same thing
odd shadow
I'm pretty sure that was the documented way of doing this when I wrote this script back in, uh, 2014
fair girder
Right and we determined that was a brittle approach that will lead to sporadic timeouts, especially as the number of transactions increase
We have a support article about this here
Also, the error message was correct. But what was not clear is that, for the API version you were using, passing total_count was the default.
Upgrading your SDK also set the API version for that request to the latest version. This omits attempting to count all the Balance Transactions on your account for every List request, which was part of the reason for the timeout.
odd shadow
OK, I've switched over to using created instead of available_on. Hopefully this will last me another few years or so!
fair girder
I would also caution you that there have been A LOT of breaking changes between 2014 and current API versions. Including the fact that all our SDKs now pin to specific API versions
odd shadow
Good to know. Luckily, this particular script has a very narrow scope.
fair girder
That makes sense. Hopefully you can carefully upgrade API versions without any unpleasant impacts.