Is this expected behavior? Is there a limit to the number of updates an instance can have? What’s the suggested solution if there can be more updates than this limit? The Updates object does not seem to support filters besides ID.
This is because you’re retrieving a single update (limit: 1) per page. You’re getting to page 10000 trying to get all of the updates by looping 10000 times?
If you increase the limit to something reasonable, you’ll need far fewer pages.
This is more of a technical/development question. I understand the limit and that it is likely not a problem in most cases. This is a finite series - meaning there is a theoretical limit to the number of updates I can retrieve from the API. Something like:
Is there a reason behind this limit for this specific object? The other objects seem to work with page * limit beyond 10,000. I’m asking for the worst-case scenario where a client might have more updates than this, or is that not possible?
There is also a hard limit of 1000 updates per item. Which is why I’m shaking my head here, you’re trying to account for an impossibility.
Another thing, the limit is just how many updates to return. Lets assume there are 100 updates.
limit: 50, page: 1 returns updates 1-50
limit: 50, page: 2 returns updates 51-100
limit: 200: page: 3 returns nothing, there are no updates 401-600 (it assumes pages 1 & 2 were also 200 updates in size, 1-200, and 201-400)
Just because other ones don’t throw an error with a limit over 10000 doesn’t mean they can return more than 10000. Most are limited to 1000 actual items. you specify 10000 and they just return 1000. Thats if the query doesn’t error/timeout at 1000 (your query must return in 60s or less).
items_page is limited to 500 items, even if you specify a higher limit. Most root queries are limited to 100 I believe.
