29

On the new History beta site I have the privilege to approve tag edits already but my own edits still go into the review queue. And the review dashboard displays a different number of pending edits depending on where I am: on https://history.stackexchange.com/review/first-answers I see one pending edit, on https://history.stackexchange.com/review/suggested-edits I see none. I am pretty sure that the pending edit being displayed is my own - I edited a tag wiki and that edit hasn't been approved yet. It shouldn't be counted no matter where I am.

screenshot

1 Answer 1

22

Yep, you could call this a bug, that's certainly valid. However, this value is displayed on every page load and cached for the system overall.

It's a classic trade-off case between accuracy and performance, and in this case we're okay with 99% accuracy vs a severe degradation and complication on the performance side. I wouldn't expect this to change any time soon, it'll stay this way for performance reasons.

11
  • 4
    This is [status-will-not-be-completed].
    – Himanshu
    Sep 19, 2013 at 7:14
  • This behavior is still present with the revamped site status bar ... although oddly it reports and invisible "2" suggested edits when I go ahead and do "1" tag wiki edit. That wrinkle might be a new bug.
    – Erics
    Jan 19, 2014 at 4:15
  • 1
    @hims056 - there's a [status-declined] for bugs/feature requests that the SE team has no plans to implement/fix. That would be a better fit than 'by design'
    – Robotnik
    Feb 2, 2014 at 23:20
  • 1
    Is it really that big of a performance hit to check that the suggested edit is not your own considering the system already knows not to notify about suggested edits you already reviewed, but which are still waiting for other people to review it?
    – 3ventic
    Mar 5, 2014 at 14:37
  • @3ventic yes, because instead of caching an integer per site it would be cached number per user, generated from a list evaluated per-user. So it's either an dual cache hit from the miss then global for specifics, or a list check every time we render a page - both are incredibly more expensive than fetching an integer from a memory reference. Mar 5, 2014 at 15:35
  • 1
    @NickCraver But a site-wide cached number shouldn't change after I review it when I was the first to review and the review stayed in the queue for a few minutes.. What am I missing here?
    – 3ventic
    Mar 5, 2014 at 15:41
  • @3ventic Reviews aren't by a single person, they have to be approved or rejected by multiple people, hence the number for you is different than for another user - we'd have to do it for every user, or do some crunching in the page load, which adds load time for little benefit. Mar 5, 2014 at 15:44
  • @NickCraver There's my point: if the number is different for me than for another user, does that not make the number generated specially for me?
    – 3ventic
    Mar 5, 2014 at 15:47
  • 1
    @3ventic yes, but any action by any user or the sync job may (almost certainly will) affect that number. It has to be purged and recalculated every time, or we maintain a review list in memory on every web server that we have to sync and eat the expense every page. Either way yes, it's tremendously more expensive than the current, simple approach. Mar 5, 2014 at 15:50
  • 1
    @NickCraver - Just stumbled back across this after the same thing was re-asked on Arqade and wanted to ask: You say 'we' could call it a bug, but does the SE team consider this a bug? If so, would you think that [status-declined] fits better than [status-by-design]? From the tag wiki: "indicates that the feature request or bug will not be implemented or fixed at the present time."
    – Robotnik
    Feb 12, 2015 at 5:29
  • 1
    @NickCraver based on newer tech, is is feasible that this could be changed without the performance issues?
    – Tim
    Jul 3, 2015 at 15:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .