Page MenuHomePhabricator

Notifications: Getting multiple "Thank"s from one user for the same edit is possible (double/duplicate)
Closed, ResolvedPublic

Description

Per https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Archive_4#Thanked_twice

It's possible to thank a user for the same edit, twice (or more).

Example: I have the history page, and a specific diff-change, open in separate tabs/windows. If I "thank" in one of those tabs, and don't refresh the other tab, then the second "thank" link doesn't auto-update to "thanked".

Given how rare this situation is likely to be, and how complicated a fix is likely to be (?), I imagine this won't be fixed/fixable. Reporting for record-keeping.


Version: unspecified
Severity: normal
See Also:
T48690: Duplicate thank you allowed
T58378: Disable thank link while waiting for the server's response, to eliminate one cause of accidental double-thanks.
T61207: Thanks given via mobile are not shown on desktop history page
T88820: Flow thanked posts aren't remembered across sessions - Flow equivalent. The implementations are separate but very similar, so the same cause applies to both.

Details

Reference
bz51303

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
bzimport raised the priority of this task from to High.Nov 22 2014, 1:53 AM
bzimport set Reference to bz51303.
bzimport added a subscriber: Unknown Object (MLST).

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.

(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.

  • 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. ***
Mattflaschen-WMF set Security to None.
He7d3r added a subscriber: He7d3r.Mar 5 2015, 4:54 PM

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

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 10 2015, 8:54 AM

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

Quiddity renamed this task from Notifications: Getting two "Thank"s from one user for the same edit is possible to Notifications: Getting two "Thank"s from one user for the same edit is possible (double/duplicate).Apr 29 2015, 5:12 PM
Quiddity added subscribers: Florian, Moushira, Krenair and 4 others.

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.

EoRdE6 added a subscriber: EoRdE6.May 19 2015, 9:51 PM

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

EoRdE6 renamed this task from Notifications: Getting two "Thank"s from one user for the same edit is possible (double/duplicate) to Notifications: Getting multiple "Thank"s from one user for the same edit is possible (double/duplicate).May 19 2015, 9:54 PM
EoRdE6 updated the task description. (Show Details)

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

Legoktm closed this task as Resolved.Jun 22 2015, 9:10 PM
Legoktm claimed this task.

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

Legoktm reopened this task as Open.Sep 22 2015, 5:31 PM

This happened again :(

https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=thanks&user=Mjroots&page=User%3ARedrose64&limit=2&offset=20150918060000

Looking in the database shows that both log entries have the same exact timestamp, which seems fishy:

| 69116086 | thanks   | thank      | 20150918051707 |   408438 |             2 | Redrose64                       |             | a:0:{}     |           0 | Mjroots       | 22993657 |
| 69116087 | thanks   | thank      | 20150918051707 |   408438 |             2 | Redrose64                       |             | a:0:{}     |           0 | Mjroots       | 22993657 |
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 22 2015, 5:31 PM
Legoktm removed Legoktm as the assignee of this task.Nov 19 2015, 11:34 PM

I'm not actively working on this at the moment.

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.

MariaDB [metawiki_p]> select * from logging_userindex where log_type = 'thanks' and log_action = 'thank' and log_user_text = 'Ktr101' 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 |
+----------+----------+------------+----------------+----------+---------------+-----------+-------------+------------+-------------+---------------+----------+
| 16665308 | thanks   | thank      | 20160412045820 |   232417 |             2 | MZMcBride |             | a:0:{}     |           0 | Ktr101        |    64607 |
| 16665309 | thanks   | thank      | 20160412045820 |   232417 |             2 | MZMcBride |             | a:0:{}     |           0 | Ktr101        |    64607 |
+----------+----------+------------+----------------+----------+---------------+-----------+-------------+------------+-------------+---------------+----------+
2 rows in set (0.40 sec)

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

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 11:02 PM

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 ?

Restricted Application added a project: Growth-Team. · View Herald TranscriptAug 30 2018, 5:46 PM

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

Quiddity updated the task description. (Show Details)Oct 16 2018, 6:36 PM

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.

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.

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.

SBisson closed this task as Resolved.Oct 22 2018, 10:51 AM
SBisson claimed this task.
SBisson added a subscriber: SBisson.

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.

Resolved. Until it becomes a problem again ;)

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.

Framawiki removed SBisson as the assignee of this task.Oct 28 2018, 7:45 AM