37

The current behavior is like this:

  1. A question gets closed
  2. A user edits the question pushing it into the reopen queue
  3. That same user later votes to reopen it
  4. The reopen review is invalidated

This also affects the author of the question (while a user needs 3000 reputation to vote to close/reopen someone else's question, they only need 250 reputation to vote to close/reopen their own question). This can diminish an OP's chance to get their question reopened.

The behavior is based on edits and flags, since votes to close/reopen are internally also just flags. In many cases this mechanism is useful and prevents abuse.

In case of edits and votes to reopen the potential abuse would be to push a question into the reopen review queue twice, once by editing, once by voting to reopen. It's all not as easy as it sounds, though. Shog9's answer to (3) describes what you'd have to do to abuse it:

So the question'd have to be closed immediately, then you'd have to cast your reopen vote pretty quickly thereafter, the question would have to go through review promptly, get no more reopen votes for four days, and then you'd have a bit less than a day to make your edit and hope the review went your way... 'cause on day 5, the task would once again become invalid.

I suggest to change the behavior. It depends on what is easier to implement but possibilities are

  • ignoring reopen votes and allowing the loophole (preferred by Shog9 ("In spite of this obscure loophole, I kinda prefer this option: it's dead-simple."))
  • introducing checks for the actual case to be prevented

Sources:

(1) When is a review task “completed” or “invalidated”?

(2) Why is the Reopen queue invalidating tasks when a reopen vote (to reopen) comes in after an edit (by the reopen voter)?

(3) Why was this Reopen review item invalidated?

19
  • 21
    It is best the system doesn't have surprises. This behavior surprised me and it is infuriating for a user if they do all the things our guidance tells them to do and then the end result is hindering getting good answers on an improved question.
    – rene
    Commented Mar 19, 2021 at 8:43
  • 1
    I'd say Shog9's option seems to be the best one - one needs to be pretty damn inventive (and motivated) to land in the window of opportunity for the loophole to take effect for little gain (certainly not worth the trouble). Plus, an intentional abuse can be spotted and reported (if that can even be called "abuse").
    – Oleg Valter is with Ukraine
    Commented Mar 19, 2021 at 11:16
  • @OlegValter I think it's possible to send a post to the reopen queue multiple times, no? Just wait for the reopen vote to expire and cast a new one. I've seen it mentioned that this can be done by the same user over and over, so I'm not sure how exactly this current "feature" would be preventing "abuse" by closing any so-called loopholes.
    – Scratte
    Commented Mar 19, 2021 at 11:22
  • @Scratte - I am not sure I follow what you mean here? Isn't the problem with the current behaviour invalidating the reopen review task, not with sending posts to the queue multiple times? I meant that the hypothetical loophole does not seem harmful, so the behavior seems safe to reevaluate.
    – Oleg Valter is with Ukraine
    Commented Mar 19, 2021 at 11:46
  • 1
    @OlegValter I meant that the loophole that the current functionality seeks to prevent, isn't prevented. A user can still send a post to the queue multiple times. Hence, there's no reason for it to work the way is currently does. It just brings frustration with its surprising behaviour.
    – Scratte
    Commented Mar 19, 2021 at 11:51
  • @Scratte - so, we do not disagree then? I was talking about the potential loophole only in a sense that even if it matters, its effort/reward ratio is so low, that it should not be a concern if we are to improve the flow for well-intentioned users.
    – Oleg Valter is with Ukraine
    Commented Mar 19, 2021 at 12:03
  • @OlegValter We are in agreement :) I just wanted to add that the loophole isn't even closed, because when I read the post by Shog9, I spend quite some time trying to figure out how exactly it was closing this loophole, hence the justification for even having this frustrating functionality.
    – Scratte
    Commented Mar 19, 2021 at 12:07
  • 3
    @nbk Why should it be deleted? If it's edited to be a fine Question. If it's your Question that you edit to get reopened, why would you not want to vote to reopen it? Note also that it's impossible to know if a post is in the queue until it's already left the queue. There's no entry in the timeline while it's in the queue.
    – Scratte
    Commented Mar 19, 2021 at 13:29
  • 1
    @nbk Users can vote to reopen their own post at 250 reputation points (is this a case where you didn't know how the site works? :-). I'm also not sure that punishing a user by deleting their now fine post just because of what they didn't previously know, but have since learned, is a constructive way of moderating users. You can step it up to deleting entire accounts at 10K if they make a mistake.. that'll teach them! :P At least that way we'll have new blood here at all times ;)
    – Scratte
    Commented Mar 19, 2021 at 15:03
  • 7
    @nbk I disagree. I did not know that voting to reopen a post would kick it out of the queue. I'm sure this came as a surprise to a lot of users. I fail to see not knowing that is so horribly bad. We're not all knowing about every little quirky detail of the underlying business logic that is working on the bits of 0's and 1's that make up the site. That would be a full time job with a working brain of perfect memory. I'm sure not even developers know it all. I know that a lot of users don't know that editing a closed post puts it into the reopen queue. Even fewer know that is only happens once.
    – Scratte
    Commented Mar 19, 2021 at 15:58
  • 7
    The 5 day timeframe for edits pushing questions into the reopen queue mentioned in the quote included in this post is no longer accurate. That timeframe has been extended to 70 days as of probably more than a year ago. It was progressively increased to that value over time. Please see Lots of questions in the reopen queue for a description of the criteria for which edits put questions into the reopen queue. IMO, the difference between 5 and 70 days for body edits pushing into the reopen queue doesn't materially affect the arguments for this change.
    – Makyen Mod
    Commented Mar 19, 2021 at 16:19
  • 2
    I may miss something here, but isn't the first surprise in that flow at step 2? I never understood why an edit (moreover by a third party user) would trigger an hidden and unrelated task to push the question into the review queue. If I want to have a question reopened, I click the button labelled "reopen", I don't enter a konami code hoping for something.
    – Kaiido
    Commented Mar 22, 2021 at 23:54
  • 1
    @Kaiido It seems that Should questions be added to the reopen queue as soon as they're edited by the original author? caused the implementation of that feature ("He also mentioned that questions almost never get reopened once they're closed. Should more questions be added earlier to this queue. I think that after a question is closed, if the original author makes a substantial edit to the question, it should be eligible for reopening."). That edits by non-OPs should cause this is debated.
    – Jeanne Dark
    Commented Mar 23, 2021 at 7:14
  • 1
    @JeanneDark still I don't understand why the edit is the trigger for this action. Why don't we just present the "reopen" button to OP, maybe even locking it until such an edit occurs, I don't mind. From my point of view, having a clear "reopen" button being the only way to trigger this action would solve all the hacks required now to avoid the weird timings thing Shog talked about, since OP has the power to push their question to the queue when they want, no need to let them polish their multi-edits and the impromptu double vote thing at hand here would also be solved.
    – Kaiido
    Commented Mar 23, 2021 at 7:25
  • 6
    We are going to investigate and see how this fits in to our current roadmap work.
    – Rosie StaffMod
    Commented Mar 23, 2021 at 16:53

2 Answers 2

Reset to default
16

I'm happy to report that as part of our future changes to the question reopening experience, this bug will no longer occur. 🎉 The older logic was complex and buggy, and we've replaced it with something simpler that guarantees the edit will enter and stay in the review queue even if the user has voted to reopen the post.

I've also created an automated test that reproduces the problem exactly. The test fails in the old reopen queue workflow, but passes in the new reopen queue workflow. I can confirm that Shog's steps to reproduce were correct (thank you!). The flow of the automated test is:

  • A test post is closed
  • A test user then edits that post in a way that would put it into the reopen queue
    • In the old workflow, this happens with an edit to the body within 70 days of the post's closure during the next queue sync
    • In the new workflow, this happens with an edit that is significant right after editing
  • The reopen queue is synced
  • Later, the same test user adds a flag for reopening the post
  • The reopen queue is synced
  • Both the reopen review task and the reopen vote should still exist and should not have been invalidated

This automated test helps us show that the problem no longer exists while also helping us prevent this problem from appearing again in the future.

I'm going to mark this as , but please note that this bug will still occur until the review workflow changes have released, approximately in the next couple of weeks.

2
  • So, what will be the new logic? If it has a substantial edit or a vote to reopen and the review task is not older than 4 days?
    – Braiam
    Commented Aug 13, 2021 at 11:21
  • @Braiam That sounds correct, but I'll defer to the future release post that will have all of the details when we launch.
    – Kyle Pollard StaffMod
    Commented Aug 13, 2021 at 15:02
12

The current behavior is like this:

Not quite...

Sorry to be pedantic here, but I just had to correct an edit to an old answer, and I suspect there's some misinformation floating around.

(Ok, I still occasionally read the SOCVR (Stack Overflow Close Vote Reviewers), so I know there's some misinformation floating around)

This bug is somewhat more complicated than just "if you vote and edit it invalidates the review". I went into detail on this in the answer you linked, but to summarize:

  • The edit has to be what actually put the question into review.
  • The reopen vote has to come after the edit has already put the question into review - this means after the edit is submitted and after the queue is next synchronized (this may have changed and probably will change in the future; used to be every 5 minutes or thereabouts).
  • There cannot be any other reopen votes older than 15 minutes when the queue is synced - that's what makes the vote ineligible, while the vote also makes the edit ineligible.

In other words, it's a bit harder to hit this bug than it sounds. Not that that makes it any less crappy; to avoid it with certainty, you either have to already know it exists before you edit, or you have to possess information about the state of review that is not easily possible for you to possess. That is entirely unreasonable!

Back when I first encountered this, I checked for other occurrences; it was very rare. It might be more common now though, especially on Stack Overflow: changes to closing at the tail end of 2019 resulted in a significant increase in reopen vote effectiveness and in voting - if that result held over time (I have no way of knowing), then it stands to reason more folks would hit bugs related to reopen votes. In other words: even though this requires a fairly specific set of circumstances, those circumstances might exist more often now than they once did.

I would strongly encourage the team to actually investigate this (or just exclude reopen votes from invalidating the task and the 15 minute waiting period - both are based on assumptions made almost 9 years ago now, are very unlikely to be needed anymore, and make the query unnecessarily complicated).

But for the rest of us, it's not worth worrying about too much; if you want to be extra-sure to avoid it, just get in the habit of voting immediately before submitting an edit. And note that edits made from the reopen queue are recorded at the same time as the associated vote, and thus are also immune from this bug (even if something else were to remove the initial trigger that enqueued the post).

7
  • I would assume this mostly hits users that are fairly new to the site. They've edited their post and is waiting to get it reopened. After some time they try to figure out what more they can do and ..hits this :( I believe they'd be unlikely to go and search meta before voting to reopen their own post.
    – Scratte
    Commented Mar 26, 2021 at 2:10
  • 2
    Could be; no way to know. It's a shitty bug; it punishes the folks who put in the most effort. 😖
    – Shog9
    Commented Mar 26, 2021 at 2:12
  • Another curious thing is that the first post I noticed this on had gotten a second reopen-vote, by another user that never edited the post, an hour after the post was kicked out of the queue. That reopen-vote didn't cause the post to re-enter the queue.
    – Scratte
    Commented Mar 26, 2021 at 2:22
  • 1
    Yeah, that's because only the first (active) vote will put a question into queue, and the original vote was still active. Happens a lot with close votes too; never figured out a good solution to that that didn't greatly increase complexity.
    – Shog9
    Commented Mar 26, 2021 at 3:26
  • 5
    And here I was thinking SOCVR was the single source of truth ... thanks for still watching our back.
    – rene
    Commented Mar 26, 2021 at 7:12
  • "There cannot be any other reopen votes older than 15 minutes when the queue is synced" that was also my understanding, which was why I got embroiled in a big argument when I said "I don't care" when I edit vs vote to close.
    – Braiam
    Commented Mar 26, 2021 at 14:22
  • 3
    Here's the thing, @Braiam: this sorta stuff barely matters for very active folks like yourself (and probably most of SOCVR) - it's unlikely you'll hit it, a drop in the bucket if you do, and you know where/how to get help if it does occur. But... It's yet another barrier for folks who are trying to learn the basics of the system, yet another obscure and non-intuitive pitfall, one of 1k little cuts that add up to block their hope of success.
    – Shog9
    Commented Mar 26, 2021 at 19:52

You must log in to answer this question.

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