"Thank action failed (error code: invalidrecipient). Please try again." when trying to thank MassMessage extension bot
Closed, DuplicatePublic

Description

I thanked a message in my (Flow) talk page at MediaWiki.org, and I got this error message:

Thank action failed (error code: invalidrecipient). Please try again.

As a user, there is nothing I can do, since the recipient is predefined.

The "Thank" links should not be available for posts that are made by bots. This will match the current setup on history/diff pages. (e.g. and e.g.)

Note, this is controlled by $wgThanksSendToBots .

Qgil created this task.Sep 28 2016, 9:48 AM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptSep 28 2016, 9:48 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Note that the specific comment was created by MediaWiki message delivery / the MassMessage extension.

Johan added a subscriber: Johan.Sep 28 2016, 1:54 PM

It's probably a good thing you can't thank the MediaWiki message delivery bot (if nothing else, it means you're told the person who sent the message didn't see the thanks, instead of it being sent to a black hole and you thinking you've thanked someone). But the error message is not helpful in this case.

Qgil added a comment.Sep 28 2016, 2:25 PM

Ah, at least I understand the problem now.

Trizek-WMF renamed this task from "Thank action failed (error code: invalidrecipient). Please try again." to "Thank action failed (error code: invalidrecipient). Please try again." when trying to thank a bot.Sep 28 2016, 2:41 PM
Trizek-WMF added a subscriber: Trizek-WMF.

Then, the idea behind that task would be th have a clearer message?

Johan added a comment.EditedSep 28 2016, 3:42 PM

I'd say that is the best solution – thanking the message system isn't going to be very useful, and even if it were feasible and technically simple, thanking the person who sent out the message is probably not desirable either.

Maybe I'm an edge case here as a very regular user of the MassMessage function, but as a potential person being thanked, I don't want thanks for sending out a message that in practice ends up as more than 600 individual posts, many of them community pages read by a fair number of editors. That would likely be more of a hindrance than useful.

It should not be possible to thank a bot. Those "Thank" links are already removed from History/Diff pages for exactly this reason.

This task's resolution should be removing the "Thank" links from Flow posts that are made by bots.

Quiddity updated the task description. (Show Details)Sep 28 2016, 4:30 PM

I've never used MassMessage but I found it strange that the edit be attributed to some bot. Clearly there is a human with an account initiating the action, MassMessage is just the batch delivery tool. It's like sending an email with 25 people CC'd. They receive it from me, not from Google Batch CC Service(tm).

Also, the ~-based signature in a Flow post goes against what Flow is trying to promote.

The volume of thanks problem is not unique to this case. It's possible to edit (or revert a bad edit) on a popular article and receive hundreds of thanks. We're trying to make it easier to deal with by bundling thanks notifications.

I'm sure there are technicalities I don't know about that make it more complicated but from a product perspective, I think we should be able to thank the person for the message without the tool getting in the way.

@SBisson, MassMessage has been think for classical talk pages. At that time, the important is to have the message displayed on user talk pages, not to have correct attribution (illogical, but that's how it is).

For instance, I've received that message on my volunteer talk page. It is signed by the person who had sent that message. In History, that's different.

There is no field on MassMessage at the moment to add your name as sender: you have to sign the message: if you don't no-one will know that's you who has posted that, even in Flow. :/
Have a fix would help to solve that attribution issue and receivers would be able to thank sender. It is still possible to identify a message sent trough MassMessage by using a tag.


I think there is no reason to thank a bot or an automated service. A bot flagged edit should not be thanked. It solves the question of volume.

I've never used MassMessage but I found it strange that the edit be attributed to some bot. Clearly there is a human with an account initiating the action, MassMessage is just the batch delivery tool. It's like sending an email with 25 people CC'd. They receive it from me, not from Google Batch CC Service(tm).

That feature-request is at T71954: Add support to MassMessage to allow using the sender's username for deliveries with some discussion about potential pros and cons in the comments.

The volume of thanks problem is not unique to this case. It's possible to edit (or revert a bad edit) on a popular article and receive hundreds of thanks. We're trying to make it easier to deal with by bundling thanks notifications.

That comparison doesn't work very well though, because it's comparing:

  • 1 edit at a single location, that might receives hundreds of thanks. (IIRC this would be bundled, too)
  • hundreds of edits each at a separate location, that each might receive a thank.

I'm sure there are technicalities I don't know about that make it more complicated but from a product perspective, I think we should be able to thank the person for the message without the tool getting in the way.

Yup, a reasonable perspective. :-)

This is essentially a special case of T86211: Thanking a bot-flag user in Flow, triggers an error message. The generation of the "thank" link is within Flow, and that code does not check bot flags or whether thanking bots is allowed locally.

happy5214 renamed this task from "Thank action failed (error code: invalidrecipient). Please try again." when trying to thank a bot to "Thank action failed (error code: invalidrecipient). Please try again." when trying to thank MassMessage extension bot.Mar 19 2017, 12:14 AM
Popsicleface048 closed this task as Declined.Dec 13 2017, 11:08 PM
Popsicleface048 triaged this task as Lowest priority.
Reedy reopened this task as Open.Dec 13 2017, 11:13 PM
Reedy raised the priority of this task from Lowest to Needs Triage.
Restricted Application added a project: Growth-Team. · View Herald TranscriptAug 30 2018, 5:04 PM