I regularly get hundreds of responses to observations at a time - 80-200 a day (and occ several times a day) is average. But if I open the observations too rapidly I get a “Too Many Requests” report on all the tabs after about 20 observations. However, if I accidentally close my page, then all the responses are lost (presumably marked as done), and they no longer display. So I have to open as many as possible, in as few batches, otherwise I lose them.
Can we please have a tool that opens all the outstanding observations in tabs, without generating “too many requests”, and without losing what we have not opened?
I also wont mind if multiple comments, IDs and faves are presented only once per observation, rather than repeated for each instance.
And yes, I have switched off all agreements years ago. This is purely new IDs, comments and faves.
((I did look for similar topics ( seem to remember this), but cannot find it: I cannot believe that I am the only user with this problem!))
You’re talking about going to the notifications drop-down and opening each one in a new tab?
The “Too Many Requests” response is basically because you’re hitting the limit on how often you can contact the iNat servers. They don’t know whether you’re opening new tabs from notifications, or using an automated program or what, so it’s hard for them to sometimes allow extra requests and sometimes limit them. So technically not really a bug.
The good news is that notifications are being revamped right now anyway – Carrie and Tony’s presentation had a preview screenshot. I don’t have any further information about that, but maybe someone from staff will weigh in.
Ahead of the revamp, the workaround I use for my ~200-900 notifications per day in Chrome is extension OneTab, https://www.one-tab.com/
After you open a large batch, you can use an easy context menu to throw all the opened pages into a OneTab listing of their clickable links. The 429’s are still titled 429 in that listing, but you can click on them easily to see the actual obs without having to refresh tabs.
Also, you can let the OneTab listing build up with days’ worth of notification batches until you get back around to them.
Thanks for the link to the presentation. Most interesting.
I just received this error as well, but after what I would define as greatly under what the threshold should be to trigger it. I opened 10-15 new tabs in quick succession via hyperlinks, and it triggered the error for most of them. I then waited 30 seconds and tried opening only 3-4 tabs quickly, and that also triggered it. Surely this case isn’t exceeding the request limit?
The response also seems to be very inconsistent/‘random’.
I just tested opening up several batches of 5-6 new tabs, and half worked, half gave the error (with the errors mixed in between, not just the last 3)
Each observation page initiates several API calls, and with a per-minute request limit, it is entirely possible that opening 15 pages within seconds will make enough API calls to go over the throttling limit. The per-minute request limit is a rolling window, so each second the number of requests during the last 60 seconds is assessed, and if that value is over the limit you’ll be throttled. So if at one second you were just below the limit, a page will load, and if loading that page makes you go over the limit the next page may not load, etc. So it’s not uncommon to see the “random” behavior you saw when you’re right around the limit - that’s just a side effect of the rolling window of the request limit.
We try to keep the limit reasonably high where it is effective for preventing excessive load from scrapers and crawlers, while minimizing impact on real human users. Does this happen often to you, or just in this case of opening a lot of tabs at once?
it was just this one case that I’ve experienced it