0

Feature Request: Tie review queue extensions to the contributor's account, not to their browser (and thus their device).

Background

Per The Complete Rate-Limiting Guide, the limit per contributor is extended to "40 reviews per queue per day if the queue size is 1000 or more (150 on Stack Overflow)"—assuming, of course, the queue doesn't subsequently recede below a lower threshold (≈120 on Stack Overflow).

Limitations

This extension, however, appears to be tied to a specific browser, and not just the contributor's account. As such, if I am allotted the extension on one browser, then switch to another browser after the queue size has receded below 1000 (or 150 on Stack Overflow), I won't be able to continue my reviews on that browser—even if the queue size remains above the lower threshold. I assume this might be tied to a session variable?

Update: This is not due to the queue being reduced between switching browsers; I can go back-and-forth with one consistently showing a limit of 40 (and accepting reviews), and another showing a limit of 20 (and thus not presenting new reviews). Next time, though, I will need to confirm that the cached queue size is the same between browsers.

Update: There's skepticism in the comments about whether this behavior even exists. I will attempt to document this with screenshots next time. In the meanwhile, I'd encourage members of the community to try to reproduce this themselves the next time they're granted a rate-limit extension.

Why is this even a problem?

If I am allotted the extension while using a mobile device, I want to switch to a desktop device (if available) so it's easier to write comments or make edits. On Stack Overflow, at least, queues like Low Quality Posts, First Answers, and Late Answers rarely exceed the extension threshold for long, due to the number of reviewers. As such, that extension is effectively restricted to a single device.

Edge Case?

I don't expect most people check the review queue unless they're on a device where they're able to commit to doing reviews, so this probably isn't a widespread problem. And, of course, from a platform perspective it doesn't really matter so long as the queues are handled by someone. Nevertheless, I find the limitation unexpected, and it can encourage performing reviews on suboptimal devices. (In my case, that means writing fewer comments, and only prioritizing the most critical edits, since e.g. typing backticks for inline code references is tedious on most mobile keyboard layouts.)

Given this, I wouldn't consider this a high priority—but it's nice-to-have if it's a relatively simple fix.

11
  • 7
    I don't think it's per-device. I think it has something to do with the fact that the count used to determine the review limit is cached: by the time you switch devices, the cache updates and your review limit goes down, whereas if you're on the same device, the cache doesn't have a chance to update and you can continue. Commented Nov 11, 2021 at 20:03
  • 2
    I think one day I reviewed 25 out of 40 tasks in a day, then the queue size cached count dropped and it said I reached my review limit, while on the same device. Commented Nov 11, 2021 at 20:04
  • 4
    There is no extension granted. You would no longer be able to review on that device either once the cached count for that queue drops, regardless of how much you reviewed. Switching devices had nothing to do with your ability to review further.
    – animuson StaffMod
    Commented Nov 11, 2021 at 20:23
  • @SonictheAnonymousHedgehog: Ah, so you're saying that there isn't actually a lower bound—what I estimated at 120 on Stack Overflow—but that's just an artifact of the cache being updated to reflect the current queue size? And that's why, sometimes, the extension will appear to be granted at e.g. 140, while other times being revoked at e.g. 125. I.e., it's always responding to 150 (on SO), but there's a lag in how long it takes for that to be reflected in extensions? Commented Nov 11, 2021 at 20:31
  • Yes, precisely. Commented Nov 11, 2021 at 20:32
  • @SonictheAnonymousHedgehog: Regardless, the user experience is the same: A limit of 40 on one device, with a limit of 20 on another device. When this occurs, I can go back and forth between devices, and the mobile device (in my example) will consistently be set to 40, while the desktop will consistently be set to 20. Why would this be cached client side? I'd expect any caching here to be on the server? Commented Nov 11, 2021 at 20:32
  • @SonictheAnonymousHedgehog: Or is the issue that the queue size is user specific? E.g., if I flag 100 posts in a day, the number of posts available for me to review might be below the threshold? (Since I can't review posts that I flagged.) Commented Nov 11, 2021 at 21:12
  • Yeah, the (cached) number shown on the review page doesn't include tasks that you've reviewed. The limit doesn't take into account those, though. Commented Nov 11, 2021 at 21:18
  • 1
    @JeremyCaney I'm not sure what you're referencing, and that shouldn't be possible. When you submit your review, the system always checks your number of reviews vs the maximum currently allowed, based on the current queue size. If the queue size has dropped since you loaded the task and you are no longer allowed to review it, you'll get thrown a permissions error. It's not possible to continue reviewing on one device while being blocked on another. The behavior you seem to be describing does not exist.
    – animuson StaffMod
    Commented Nov 11, 2021 at 21:28
  • @animuson: I have definitely witnessed the behavior you're talking about where the queue drops below a certain threshold, my review limit is reduced back to 20, and the review I just submitted is rejected. But that's separate from what I'm talking about. Last time this occurred, I double checked the behavior three or four times because it seemed really surprising. Commented Nov 11, 2021 at 22:29
  • 2
    @animuson: The next time this happens, I'll attempt to take some screenshots with the time visible to help demonstrate the behavior. (Unfortunately, I just missed such an opportunity because I had my head down in code.) Commented Nov 11, 2021 at 22:34

0

You must log in to answer this question.

Browse other questions tagged .