I don’t think this is working properly if the topic is closed with a topic timer. We’ve had a few users report that this is a problem. We’ve just had it again and assuming he is correct when he says he is out of votes, he (at time of writing) has 20 votes cast (which is our limit) and one of these topics is closed, so he should have one spare vote.
We’ve had this mentioned a number of previous times, but they have always told us after they have “removed” their old votes so I’ve been unable to verify it. 99% of our votable threads are closed via a topic timer of a number of days since the last reply, so I suspect the bug may be originating here?
We’re on the latest plugin version and very recently updated discourse itself:
I’m chasing down a similar issue. I think it’s cropped up a couple of times before but as yet I don’t think we’ve put our finger on the ‘why’.
I’ve just tested it with a topic timer for ‘Close after last post’ (hoping it was the missing piece I was looking for ), but my vote was returned as expected when the timer fired.
Is there anything else special about the topics you’ve noticed this occurring on?
Also, if you have the data explorer installed/enabled you can have a look at any past topics where the topic is closed and/or archived but the votes haven’t been returned using this query:
SELECT
dvv.topic_id,
t.last_posted_at::date,
tvc.votes_count
FROM discourse_voting_votes dvv
JOIN topics t ON t.id = dvv.topic_id
JOIN discourse_voting_topic_vote_count tvc ON tvc.topic_id = dvv.topic_id
WHERE dvv.archive = false
AND (t.closed = true OR t.archived = true)
GROUP BY 1,2,3
ORDER BY 2
As I said before, most of our topics are closed via a topic timer, but I think all but one of those would have been closed with the “Close topic” button (and possibly all of them). Is there a way to check how a topic was closed? So, contrary to my guess of the timer being the problem, it’s a huge coincidence that the problem seems to be on topics closed using the normal close button instead. A tiny percentage of closes will be via this button, so for this to be 6 or 7 of the 7 examples, this points very much to that button being related.
It looks like it’s all votes on a topic that don’t get returned, not just a portion of th
Two on the same day. Maybe just a coincidence.
The last topic was deleted by the poster.
Other than my first point above, I can’t see much of a pattern, but feel free to look at the threads yourself in case you spot something
Is there a way to give these back to the users manually now? Or even an automated nightly correction until the root cause can be found?
Unfortunately that doesn’t appear to be the cause either. I think there’s still something else adding to the mix as well that’s causing it to occur in some but not all cases.
To test a theory out, is there one you could reopen and then close again to see if that shakes the votes loose? (it should also give them back if they’re moved category to a non-voting one as well, which may be worth a test. And then move back to see if the problem persists)
I think we may have identified a scenario that could match yours. Your edit histories aren’t public, but it looks like you may have added a tag to these ones after they closed? If so, I think we may have a fix in the pipeline to prevent the system from re-marking those votes as ‘current’.
Yes, that gives the votes back (according to the data explorer report)
Ah yeah, that will be it Typically, we add a tag (often something like “idea-completed”) and then close with a topic timer. In the unusual case of closing immediately, we’ll usually also add a tag, but this may well be done before or after the “close” but within a few seconds of each other (I’ve never really thought about it). This explains the “coincidence” that they were all closed using the close button!
Thanks for all the help, it’s much appreciated Looking forward to the fix release.
One topic was deleted by the author and this doesn’t seem to have given the votes back and my attempts to “Open” then “Close” don’t give them back either. What would you suggest? Or will the bug fix come with a migration to fix data, if so, we can wait for that?
This will prevent it happening in the future, though won’t fix any that already exist.
It is possible to reset them via the rails console, though if you don’t have many I think it would be easier to use the UI to trigger the ‘return vote’ mechanism if you can.
Hmmm. That’s unfortunate. You could try undeleting it and moving it to your #staff category and then closing it and archiving it there. All three of those actions should release the vote so hopefully one will work. If not, we can take the rails approach if it’s stubborn.
), but my vote was returned as expected when the timer fired. 
Typically, we add a tag (often something like “idea-completed”) and then close with a topic timer. In the unusual case of closing immediately, we’ll usually also add a tag, but this may well be done before or after the “close” but within a few seconds of each other (I’ve never really thought about it). This explains the “coincidence” that they were all closed using the close button!
That’s unfortunate. You could try undeleting it and moving it to your