Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior of reactions made by admin in group is utterly random #27419

Open
php4fan opened this issue Jan 30, 2024 · 9 comments
Open

Behavior of reactions made by admin in group is utterly random #27419

php4fan opened this issue Jan 30, 2024 · 9 comments
Labels

Comments

@php4fan
Copy link

php4fan commented Jan 30, 2024

Steps to reproduce

  1. Have a supergroup where you are an admin with permission to stay anonymous
  2. there's a bot which is also admin who posts in the group
  3. (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

@php4fan php4fan added the bug label Jan 30, 2024
Copy link

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!

@github-actions github-actions bot added the stale label Jul 29, 2024
@php4fan
Copy link
Author

php4fan commented Jul 29, 2024

Again, you should suppress that stupid bot.

@Aokromes
Copy link
Collaborator

Again, you should suppress that stupid bot.

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

@php4fan
Copy link
Author

php4fan commented Jul 29, 2024

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
Copy link
Collaborator

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
Copy link
Author

php4fan commented Jul 29, 2024

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? 🤦

@github-actions github-actions bot removed the stale label Jul 30, 2024
Copy link

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!

@github-actions github-actions bot added the stale label Jan 26, 2025
@foadk
Copy link

foadk commented Jan 31, 2025

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

Yes, this bug still exists and is super annoying. I'm an administrator of a group consisting of just me and the owner. We are both anonymous. I'm seeing their reactions as group name.
I'm able to select and send reactions to messages, but they're not seeing any of them.
Is there any plans to fix?

@github-actions github-actions bot removed the stale label Feb 1, 2025
@php4fan
Copy link
Author

php4fan commented Feb 3, 2025

Why are you ignoring this??

This still happens systematically in a few specific groups with specific (admin) users, and has been going on consistently for months. These reactions are not being sent to Telegram, or at least not to bots that are listening to updates in the chat. This has disastrous consequences. We have bots that do automated moderation tasks based on reactions by the admins, but when this happens (which is always for the affected users in the affected chats), the reactions are never received by the bot via the API. All other reactions are received as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants