What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 129 Stack Exchange communities.

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 http://history.stackexchange.com/review/first-answers I see one pending edit, on http://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

share|improve this question

1 Answer 1

up vote 18 down vote accepted

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.

share|improve this answer
3  
This is [status-will-not-be-completed]. –  hims056 Sep 19 '13 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 at 4:15
    
@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 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 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. –  Nick Craver Mar 5 at 15:35
    
@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 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. –  Nick Craver Mar 5 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 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. –  Nick Craver Mar 5 at 15:50

You must log in to answer this question.

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