Yikes. See the thread linked in first comment (permalink: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Notifications&oldid=564293462#Thanked_twice )
for an update. One user has discovered how to accidentally "thank" a multitude of times, for the same edit, via "control-clicking" on any link in the "revision history" page, after a thank has been sent/confirmed.

bsitu wrote:

After a quick review on the code, the fix should be pretty straight forward. The state of 'Thanks' is saved into user's web session. Before sending a thanks notification, just skip sending 'Thanks' notification if a previous 'Thanks' has been sent for the revision

Change 73732 had a related patch set uploaded by Bsitu:
(bug 51303) Do not send duplicate thanks notification

https://gerrit.wikimedia.org/r/73732

Change 73732 merged by jenkins-bot:
(bug 51303) Do not send duplicate thanks notification

https://gerrit.wikimedia.org/r/73732

(In reply to comment #4)

Change 73732 merged by jenkins-bot:
(bug 51303) Do not send duplicate thanks notification

https://gerrit.wikimedia.org/r/73732

I'm marking this bug resolved/fixed accordingly. Please feel free to re-open this bug if you continue to see this issue (duplicate thanks) in a few days after this change is deployed.

Re-opening, per fresh report of a doublethank (with a many hour time-gap between them) from Redrose64 at https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Doublethank

• Bug 57584 has been marked as a duplicate of this bug. ***

The problem is that we store Thanks in session data, which shouldn't be and isn't a persistent cache.

We can either create our own database table for storage, or maybe use wfGetCache( CACHE_DB )? Not sure what our options for persistent storage on the WMF cluster are.

See also: https://www.wikidata.org/w/index.php?title=Special:Log&type=thanks&user=Ricordisamoa&page=User:Lydia_Pintscher_%28WMDE%29&year=2014&month=1&limit=5

(In reply to comment #8)

The problem is that we store Thanks in session data, which shouldn't be and
isn't a persistent cache.

We can either create our own database table for storage, or maybe use
wfGetCache( CACHE_DB )? Not sure what our options for persistent storage on
the
WMF cluster are.

Making thanks log public (Bug 49087) would solve the issue.

Still happening. These two thanks https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=thanks&user=Malikhpur&page=User%3ARedrose64
were both for the same edit https://en.wikipedia.org/w/index.php?title=Category:Punjabi_folk_religion&oldid=prev&diff=594057858

• Bug 61883 has been marked as a duplicate of this bug. ***

• Bug 61883 has been marked as a duplicate of this bug. ***

Still happens to me regularly (le sigh). The history for a given page forgets I already thanked a bunch of people. Apparently the Thanks are correctly mentioned in the relevant Log though, so there's this workaround.

• Bug 70100 has been marked as a duplicate of this bug. ***

http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Disruptive_.22Thanking.22_by_non-contributor_User:Serial_Thanker:_Indef_block_needed

Another example: I was thanked twice by the same person for this edit. The log shows that they occurred 39 hours 24 minutes apart.

Got two thanks for this edit, within one second of each other, both are timed 22:45:35

OK, I've just managed to send a double thanks when viewing a page history. The first time I clicked "yes", it didn't change to "thanked", so I presumed that my mouse pointer had slipped off the hot spot, so I carefully repositioned it and clicked again. There was again no change, so I checked my thanks log to see if it had gone through - and found these two entries. Upon returning to the page history, I found that the "yes" had changed to "thanked", so there is some sort of delay in updating the screen during which mouse events are still accepted and processed.

I don't know, how Thanks works, but maybe it first save's the log entry and then really sends the thank to a person. It would (maybe) be interesting, what the api-request returned :)

The recipient says that they received two thanks notifications.

See this Village pump thread. I have received three thanks over 17 hours from the same user for the same edit.

This still happens, and is easy to reproduce by clearing cookies and using Flow in non-JS mode. In non-JS mode, a "Thank" link is always displayed even if you've already thanked that user for that comment. In JS mode, it displays as "Thanked" instead and you can't click it; this discrepancy is related to T101342: Don't make it seem user can re-thank for a Flow post when they already did; render server-side.

So if you turn off JS, you can click the "Thank" link on a post you've already thanked before, and it'll actually record a log entry and send a notification, as long as you don't have a flow-thanked cookie recording that you've already thanked them.

Change 218568 had a related patch set uploaded (by Legoktm):
Use log_search to track already sent thanks

https://gerrit.wikimedia.org/r/218568

Change 218568 merged by jenkins-bot:
Use log_search to track already sent thanks

https://gerrit.wikimedia.org/r/218568

• https://gerrit.wikimedia.org/r/218568 (branch master): WMF-deploy-2015-06-16_(1.26wmf10)

It took almost two years to be fixed properly :-(((
thanks @Legoktm!

Still happening. These two thanks both relate to this edit.

Same user again? Hrm.

There's an obvious race condition in the code flow:

• Check already thanked
• Send notification
• Add to logging table

So if a notification has been sent but not yet added to the logging table, the already thanked check will fail. We could log earlier, but it seems a bit weird to log an action before said action happens.

Or we can do some lock thing. Probably that.

T129401 points out that a trivial way to trigger this is by double-clicking a JS-powered "thank" link. We could at least make that lock on the JS side so it only sends one AJAX request.

Hmmm, I just received a duplicate thanks on Meta-Wiki: https://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=thanks&user=Ktr101&page=MZMcBride.

Change 283375 had a related patch set uploaded (by Glaisher):
ext.thanks.revthank: Prevent double clicks while API request is in progress

https://gerrit.wikimedia.org/r/283375

Change 283375 merged by jenkins-bot:
ext.thanks.revthank: Prevent double clicks while API request is in progress

https://gerrit.wikimedia.org/r/283375

This happened again on Meta-Wiki.

MariaDB [metawiki_p]> select * from logging_userindex where log_type = 'thanks' and log_action = 'thank' and log_user_text = 'Rjd0060' and log_title = 'MZMcBride' and log_namespace = 2;
+----------+----------+------------+----------------+----------+---------------+-----------+-------------+------------+-------------+---------------+----------+
| log_id   | log_type | log_action | log_timestamp  | log_user | log_namespace | log_title | log_comment | log_params | log_deleted | log_user_text | log_page |
+----------+----------+------------+----------------+----------+---------------+-----------+-------------+------------+-------------+---------------+----------+
| 20025669 | thanks   | thank      | 20170110214635 |    54474 |             2 | MZMcBride |             | a:0:{}     |           0 | Rjd0060       |    64607 |
| 20025672 | thanks   | thank      | 20170110214638 |    54474 |             2 | MZMcBride |             | a:0:{}     |           0 | Rjd0060       |    64607 |
+----------+----------+------------+----------------+----------+---------------+-----------+-------------+------------+-------------+---------------+----------+
2 rows in set (6.07 sec)

Any news here ?

I can't reproduce this bug currently. Can anyone provide reproduction steps?

In T53303#4671532, @kaldari wrote:

I can't reproduce this bug currently. Can anyone provide reproduction steps?

It seems that I no longer receive multiple thanks, at least using the web UI (possibly the API is different?). (I tried to send a thank for the same diff, from 2 different computers at the same second).
I guess the original bug is partially resolved. Possibly the remaining piece of the puzzle needs a different task? I.e.
It is still common for a user to not be able to determine if they have already sent a "thanks" or not. E.g.

• Open https://www.mediawiki.org/w/index.php?title=User:Quiddity_(WMF)/sandbox&diff=2924057&oldid=2924055&diffmode=source
• Click "thank" and then click "thank" again to confirm.
• Notice that the "thank" link has now been replaced with the plaintext "thanked"
• Close the browser window entirely.
• Reopen the browser, and the same link.
• Notice that the plaintext "thanked" has now changed back to a clickable-link "thank"

I.e. It's impossible for me to tell if I already thanked someone for a thing, if I come back to it days/weeks later.

It is still common for a user to not be able to determine if they have already sent a "thanks" or not.

Yeah, that sounds like a different problem. FWIW, the main reason it was built how it was (using the session) was to keep it lightweight and performant. I'm not convinced that this is enough of a problem to add extra database queries to all our revision interfaces to make sure people know every revision they've ever thanked.

In T53303#4672334, @kaldari wrote:

It is still common for a user to not be able to determine if they have already sent a "thanks" or not.

Yeah, that sounds like a different problem. FWIW, the main reason it was built how it was (using the session) was to keep it lightweight and performant. I'm not convinced that this is enough of a problem to add extra database queries to all our revision interfaces to make sure people know every revision they've ever thanked.

Makes sense. I agree it's probably impractical to add that for technical/performance reasons. I suggest marking this task as resolved, and not filing a new task for the other problem.

In T53303#4671532, @kaldari wrote:

I can't reproduce this bug currently. Can anyone provide reproduction steps?

The most recently reported cases were race conditions, likely caused by double POSTing despite our prevention against it...it's possible some other change in MediaWiki's database layer resolved it. I think closing this task until someone else has a new case of this happening is reasonable.