-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Very slow to pull charges for the last year. #2284
Comments
@benwmills Thanks for reaching out. Github issues should be limited to bugs with the library itself. Your question here is more about the API itself and overall latency and it would be better suited for our support team. They can look into your account, your logs and better understand what's causing this. You can contact them here: https://support.stripe.com/contact Overall, listing charges (or most resources) can be quite slow as you need to render many objects. The Charge API especially is quite a large object to render and paginate through. When listing 3700 charges sequentially you need to do 37 separate calls which can each take up to 30 seconds to complete. Overall it shouldn't be 30 minutes but it will definitely not take a few seconds (or even a minute or two). When you need to do bulk data exports, you should prefer alternatives such as the Dashboard exports, Sigma queries in the Dashboard or the API or using the Reporting API such as https://stripe.com/docs/reports/report-types#schema-balance-change-from-activity-itemized-1 instead. |
I do still think this might be a bug in the library. I was using the ListAutoPaging and it never completed. I just made a change to do manual paging using the standard List method (ListAsync actually) and each query of 100 is taking just a few seconds (like you said). I wonder if the ListAutoPaging is broken and stuck in a loop. |
@benwmills Would you be able to add some logs to the pagination logic to track where it gets stuck and provide maybe a repro? |
In my calling code? It's just the call to ListAutoPaging. Or do you mean in the code in this GitHub repo? I took a peek at the code and followed the trail from that method. I suspect it may be an issue here where it calls a sync or async method depending on the version of .NET:
I haven't tested this yet, but I also suspect that the ListAutoPagingAsync method will work just fine. I'll report back. |
@benwmills Sorry yes I meant logs in your own code. Basically does it suddenly stops returning data and there's no new log, or is the code just running slower over time and making it appear as if it's not doing anything? Also what is your environment like (exact .NET version and stripe-dotnet version)? It's definitely possible that there's a bug here though this code has been here for a while. Would you be able to also provide an example id from your account such as as Test request log id from https://dashboard.stripe.com/test/logs That would help me lookup the logs quickly on our end to see whether the requests are stopping abruptly (After being fast for a while) or if they are just slowing down/spaced out |
If you look at the code in the original post, you'll see it's just a single call to ListAutoPaging. The code works fine until that point and then that line hangs forever. I've let it run for 40 minutes before. There's not really anything to log. The versions number are in the original post too. We turned this code off at some point in the last year (it's a non essential report) and I was asked to revisit. I know it worked at some point. It always took several minutes to run, but nothing like this. It's hard to pinpoint when it got this slow. At this point, I have a workaround doing the paging myself. In my case, I have about 3700 records to pull, so I have to pull 37 pages of data, but each page only takes a few seconds, so the entire loop is maybe a minute or 2. I don't know why ListAutoPaging is still running after 40 minutes, but I have to think that it's pretty broken. Like I said, I have a feeling there's some off sync/async mix up going on in there. |
The code will run sequential calls to the List Charges API though and return a page of 100 objects at a time while you paginate through the list. It doesn't automatically go and ingest every single charge in the account. This means that you can log explicitly for each page to figure out whether the code is becoming slower over time (for example after 10 pages it takes 1 second instead of 500ms, and after 100 pages it takes 7 seconds instead of 500ms, etc.) or if it is stable and just suddenly hangs. For example you could try something like this:
This is my current output when running it for a few a bit:
|
Could this be that you're on a lib version before this fix was released? #1982 |
@clement911 Yeah I thought about that one but it was released in 35.12.1 but the original message said they are on 37.6.0. Could still be related though (version mismatch or another subtle bug of similar shape). |
@remi-stripe, I added your logging code and I never get in to the foreach loop. @clement911, that issue sounds very similar to what I'm seeing. My action method is async (another developer has been actively swapping them over to async), but we're making the regular ListAutoPaging call. I tried to switch to ListAutoPagingAsync, but then I'm getting a different build error:
At this point, I'm happy enough to manually page. ListAsync works just fine. |
I wonder if it could have something to do with the c# version you're using... |
Going to close this out for inactivity as we haven't heard any other similar reports but let us know if you are still experiencing this |
We're trying to make a simple call to get all our charges for the last year. We're using stripe.net version 37.6.0 to make this request from the .NET Framework 4.7. The code is really simple:
For some reason this runs extremely slow. I let it run for 30 minutes before I had to stop the call. We're only pulling 3,700 records, so it doesn't seem like the call should take this long.
When we download these records in the Stripe UI, it only takes a minute or 2 to build the CSV download.
The text was updated successfully, but these errors were encountered: