okay… i tested with more requests, and i finally am able to repeat the problem you noted.
i tried sending sets of requests with various incremental delay between initiation of requests, and the below table summarizes what i saw. (it doesn’t seem like it matters when the requests actually complete, only when they are initiated).
| delay (ms) | equiv req/min | 1st failed req (250 reqs) | 1st failed req (500 reqs) |
|---|---|---|---|
| 1000 | 60.0 | 120 (avg) | untested |
| 1002 | 59.9 | 150 | untested |
| 1010 | 59.4 | no errors | 418 |
| 1050 | 57.1 | no errors | untested |
| 1125 | 53.3 | no errors | untested |
| 1250 | 48.0 | no errors | untested |
| 1500 | 40.0 | no errors | untested |
at 250 requests in each set, i encountered failures only when delay <=1002ms. at 1000ms, i experienced the first failure on average at the 120th request (118, 117, 125). at 1002ms, i experienced the first failure at the 150th request.
raising my set size to 500 requests, i retested at 1010ms and experienced my first failure at the 418th request.
without doing more testing, it seems like iNat might just be doing some strange rounding or truncating somewhere when trying to figure out whether the rate has exceeded 1 req/sec.
so maybe there is a minor bug in the system after all. i would guess the problem is isolated to /v1/observations/histogram, since i know i’ve sent sets of hundreds of requests at 1 req/seq to /v1/observations, v1/observations/species_counts, and v1/observations/observers without issue in the past.
i also would guess it would be easy enough to work around the problem by targeting something like 55 req/minute instead of 60 req/minute when issuing more than 100 requests in a set.