Hello!
I ran a products query today that included the warehouse_products side of things, including the “available” field. Obviously this means that the credits required for the query were vastly increased, which is fine. It’s what I expected. I just mention this because it may be an outside occurrence, but the type and contents of the query aren’t terribly important. What I didn’t expect is that when the number of seconds remaining to be able to run the same query exceeds 60 seconds, the format of the time_remaining message changes.
For a simple query where the wait time is short, the message is simply something like “4 seconds” or “7 seconds”. I use this information to make my code pause for that number of seconds in order to re-send the query.
For a more complex query that can exhaust the 1001 credits in a single pass, and the wait time extends longer than 60 seconds, the message becomes something like “00:01:05 minutes”. I have no problem waiting for that time if I really need to get at that data. But parsing out the 00:01:05 becomes much more of a pain.
I don’t think it’s pertinent, but just in case it’s needed, here’s a request_id from a query I tried: 5fd23b7c019084e047a0bfe0
Anyway, from the information on in the developer resources, it says this about the credits:
- Users are given 1001 credits.
- Every second, 15 credits are restored (this is the increment_rate).
- No operation can exceed 1001 credits.
I want to draw attention to the second bullet point. A restore rate of 15 credits per second, the maximum number of seconds to restore the full 1001 credits would be 67 seconds. To me, considering that is this is the case, it seems like it would make more sense to just always return the number of seconds that it will take to regenerate the credits, whether it’s 4 second or 65 seconds.
Unless I’m totally missing something, would be be possible to have this message standardized to always return the number of seconds to wait instead of formatting it to HH:MM:SS after a certain point?
Thank you,
Jeremy