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

Question

Recently I asked the question about "Why do some close or reopen votes show in a timeline as invalidated instead of completed?", and part of a comment below the answer to it stated this:

... That one got invalidated because of a bug that existed back then (I believe it got fixed last year). Essentially any reopen vote causes the edit to be ignored, but the system only considered reopen votes at least 15 minutes old for review cases. So if the system updated review within that 15-minute, it would think the task is invalid because the edit doesn't qualify and the only reopen vote isn't old enough. It would kill the task and wouldn't recreate it unless a second reopen vote came in. I forget how it was fixed, I think we started ignoring the reopen vote time.

However, today I ran in yet another similar scenario, which is like so:

1. Edit a question that had status "hold" (I have sufficient rep, no need for suggested edit review queue).
2. Wait about 15 to 20 mins to have the question show up in the reopen review queue.
3. Vote about the question in the reopen review queue (I have sufficient rep to perform such review), i.e. vote to reopen the question, and as the 1st reviewer.
4. Wait a few minutes and check the timeline of the question, to then notice the reopen task got invalidated.

So it seems to me that something similar as what is mentioned in the quoted comment above has happened again. After I posted a comment below that same answer to my previous question, this is what animuson♦ added as extra comment:

@Pierre You might wanna file a bug report for the Reopen queue incorrectly invalidating tasks when a reopen vote comes in after an edit. – animuson♦

Hence my new question here, tagged as requested by animuson ...

Note: there is also this question (on meta.ell.SE), credits to gerry for the comment about that ... but the accepted answer there is, at least for me, NOT obvious to digest. While I think that, because of the nature of this question (it may probably happen on any site), the question belongs on meta.SE.

PS: I leave it to others to consider this as a bug or not (I tag it as a support question for now).

Answer 1

After posting this question, I ran in a number of variations of it, based on which I more or less seem to understand what is happening. I leave it to others to decide if that is yes or no the intended design. Read on for more details ...

Variation A

Here is a 1st variation of similar scenario described above, this time it looked like so:

1. Edit a question that had status "hold" (I have sufficient rep, no need for suggested edit review queue).
2. Wait about 15 to 20 mins to have the question show up in the reopen review queue.
3. Vote about the question in the reopen review queue, i.e. vote to leave closed the question, and as the 1st reviewer.
4. Wait for at least 45 minutes and check the timeline of the question, to then notice the reopen task WAS NOT invalidated.

The only difference in this variation (as compared to the previously described scenario above ... is how I voted (this time 'leave closed', the first scenario I voted 'reopen').

Variation B

Here is a 2nd variation of similar scenario described above, this time it looked like so:

1. Edit a question that had status "hold" (I have sufficient rep, no need for suggested edit review queue).
2. Wait about 60 mins to have the question show up in the reopen review queue, and until at least 1 other user had performed a review first.
3. Vote about the question in the reopen review queue, i.e. vote to reopen the question, so NOT as the 1st reviewer.
4. Wait for just a few seconds and check the timeline of the question, to then notice the reopen task got invalidated.

The only difference in this variation (as compared to the first described scenario above ... is when I voted (this time 'reopen' also, but NOT as the first reopen-voter).

Variation C

Here is a 3rd variation of similar scenario described above, this time it looked like so:

1. Wait for some other user to edit a question that had status "hold".
2. Wait about 15 to 20 mins to have the question show up in the reopen review queue.
3. Don't vote to reopen yet, but first open a new browser window to perform an extra edit of the question body.
4. Return to the vote to reopen browser window, and vote about the question in the reopen review queue, i.e. vote to reopen the question.
5. Wait for a few hours until the outcome of the reopen voting shows up in the timeline of the question, to then notice the reopen task WAS NOT invalidated.

The only difference in this variation (as compared to the first described scenario above ... is when I voted (this time 'reopen' also, but NOT as the first reopen-voter).

Summary

Based on the scenario's above, this is my summary of them all:

• It doesn't matter when I vote to reopen a question I edited a bit before, i.e. if I'm the very first voter, or if another user already voted before me.
• If I vote to reopen a question for which I edited the question body a bit before (so that my edit is what caused the question to show up in the reopen review queue), Then it gets "invalidated" right away. Btw: if I only edit the question title, it doesn't show up in the review queue at all.
• If I vote to reopen a question for which I did NOT edit the question before (so some other user did some edit and that is what caused the question to show up in the reopen review queue) AND I perform an additional edit before actually casting my vote to reopen, Then it does NOT get "invalidated".

With everything above in mind, the current implementation about all this seems to be like so:

If you edited a question on hold, which caused it to show up in the reopen queue AND you then vote to reopen, then the reopen voting task gets invalidated. And if you don't want to cause such reopen voting to be invalidated, then you must either NOT vote to reopen at all, or vote to leave the question closed.

My 2 cents about this current implementation: sorry to disagree with animuson♦, but I'm not sure this is a bug (cfr. quoted comment in my question), but rather something like a possible implementation that does make sense. It's just not obvious to find out what the actual implementation is ... so that you know what to do (or not do) when voting in the reopen queue.