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

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.

Ah, at least I understand the problem now.

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

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.

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.

In T146883#2677016, @SBisson wrote:

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.

Assuming resolving T173086: Remove Thanks link in Flow comments added by bots to avoid invalidrecipient error will solve the special case of MassMessage.