Behavior of reactions made by admin in group is utterly random

php4fan commented 7 months ago

Steps to reproduce

Have a supergroup where you are an admin with permission to stay anonymous
there's a bot which is also admin who posts in the group
(You) react to some of the bot's posts with an emoji

Expected behaviour

Something consistent.

If the fact that I am anonymous means I cannot react, then I shouldn't have the UI to react in the first place.

If being anonymous means my reactions are anonymous, then they should always work consistently, that is, show up and remain, be displayed without my avatar (if this is how they're going to be seen by others, it would be stupid to show them with the avatar to me), and be seen across devices and be sent to the bot via the API (yes, the bot is subscribed to message_reaction and message_reaction_count type updates)

If being anonymous means I cannot react, and for whatever reason you can't be smart enough to avoid showing a UI to do something that I can't do, then the reaction should disappear immediately, and with some feedback that let me understand what happened, e.g. an error message saying I cannot react and exactly why.

If reactions given by an anonymous admin are not supposed to be anonymous (which would be stupid) then they should work consistently, as non-anonymous reactions.

Actual behaviour

When I (an anonymous admin) react to the bot posts in Telegram Desktop, RANDOMLY any of these happen:

the reaction is displayed (to me in TD), with my avatar next to it (which makes no sense given that I am anonymous)
- and then it disappears a few seconds later OR NOT OR
the reaction is displayed without my avatar next to it (as expected)
- and then it disappears a few seconds OR NOT

In either case, the reaction never shows up on the mobile app, and the update is never sent to the bot (which is receiving updates for reactions by other users, both other anonymous admins, non-anonymous admins, and regular users).

Basically it seems the reaction never leaves Telegram Desktop, and the way it behaves locally is utterly random and inconsistent (sometimes it disappears sometimes not; sometimes it has my avatar sometimes not). And no error message is ever displayed indicating any fault of any sort.

Operating system

Manjaro Linux

Version of Telegram Desktop

4.14.9

Installation source

Flatpak

Crash ID

No response

Logs

No response

github-actions[bot] commented 1 month ago

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

php4fan commented 1 month ago

Again, you should suppress that stupid bot.

Aokromes commented 1 month ago

Again, you should suppress that stupid bot.

again, stupid bot helps us to find already fixed issues missed to close.

php4fan commented 1 month ago

again, stupid bot helps us to find already fixed issues missed to close.

LOL seriously?

If that's really what you're using it for, you don't seem to be doing anything to prevent it from closing issues on false positives.

All the issues reported by me that the bot marked as stalled (usually because there was no reply from your side, and I don't think I've ever seen one that had been fixed), one of two things happened: either I replied myself to prevent them from being closed, or they got closed.

This one still exists, in case you doubt.

Aokromes commented 1 month ago

again, stupid bot helps us to find already fixed issues missed to close.

LOL seriously?

If that's really what you're using it for, you don't seem to be doing anything to prevent it from closing issues on false positives.

All the issues reported by me that the bot marked as stalled (usually because there was no reply from your side, and I don't think I've ever seen one that had been fixed), one of two things happened: either I replied myself to prevent them from being closed, or they got closed.

This one still exists, in case you doubt.

we give fairly decent timeout to close issue after slate (30 days), and again decent time (45 days) after close issue to lock, that's 75 days or 2 months and half after warning.

php4fan commented 1 month ago

we give fairly decent timeout

You give to whom??

The bot gives you decent time to review the issue after it has been marked as stale, and I've never seen you do that (I always assumed that you were so overwhelmed with issues that you didn't have time to review all the stale ones before they got closed, which would mean that the time is insufficient).

Are you saying that you assume that the reporter will keep watching the issue and alert you if an issue that has been marked as stale (which again, half of the time happens because none of you ever even replied once to the original report) still exists? If that is the case, basically you are saying you care about issues less than your users.

You shouldn't rely on the reporter taking any crucial role in managing an issue. The reporter may have become uninterested (which has no relevance whatsoever to the importance of the issue, it's a bug report, not a support ticket), found a workaround, miss the notification, be unable to reply, or be dead for all you know.

and again decent time (45 days) after close issue to lock

Wait, you lock issues after they have been closed? 🤦

telegramdesktop / tdesktop