Closed vanyakosmos closed 5 years ago
Can't reproduce
@x0x8x because you've loaded only one session. Typo in tester_two.sesSion
and in the logs you have only 1 user printed out.
Thanks for the help.
Oh wait, I read that wrong. I still haven't tried this myself but I doubt it's a bug anyway.
Seems to work fine. Shared loops have nothing to do with different clients, at all.
wow, you can't just trust twitface. I can share with you session file of one of my accounts and you can check it yourself. And the problem wasn't specific to private chats. Just chats in general. Chats where we have several users with a shared loop on clients.
If I can't trust Twitface, can I trust anyone? We had your report for the issue, and his to say there is no issue, and I lean on the side that shared loops are not an issue. If anything, outgoing=
may be buggy. I will try myself and post results some time.
I tried in a private conversation:
async def foo(event):
await event.reply('bar')
with client, alt:
print('Are the loops the same?', client.loop == alt.loop)
client.add_event_handler(foo, events.NewMessage(outgoing=True, pattern='foo'))
alt.add_event_handler(foo, events.NewMessage(outgoing=True, pattern='foo'))
client.loop.run_forever()
Which prints:
Are the loops the same? True
Where client
and alt
are different accounts. I messaged from the client
account to the alt
account using an official client with the following result:
Only client
responded. The same occurred in a small group chat and megagroup. So this is not an issue. I can't reproduce.
Then what can possibly be wrong with my code?
code:
logs:
And here is a result:
@Lonami, you weren't able to reproduce, because alt
client wasn't active/connected at the moment.
this code "works"
BUT, if your alt
type foo then you will see a bug. Or you can just connect both clients beforehand (commented code).
In my code I do with client, alt:
which calls start()
on both client
and alt
.
but why after adding explicit "connect" the bug magically appears?
or when alt
also type something in the chat
Could you also register events.Raw
for both and print(event)
?
β¦which leads the following code to issues: https://github.com/LonamiWebs/Telethon/blob/b1eed82b7f7c793c05defeb0a504659f6f2ae761/telethon/events/newmessage.py#L92-L97
Does that fix it? (pip3 install -U https://github.com/LonamiWebs/Telethon/archive/master.zip
)
yep, it's all good now
Okay thanks for confirming and sorry for refusing this was a bug at the beginning (although the original issue never existed, this edited one did).
Checklist
pip install -U https://github.com/LonamiWebs/Telethon/archive/master.zip
and triggered the bug in the latest version.Code that causes the issue
Missbehaviour In a chat with one another, both users respond to outgoing messages of one of them.
For example: let's say that we have 2 users (A and B), both have userbots, userbots' clients have shared event loop. If users chat with one another then we will see that user A will also respond to the outgoing command of user B. (
>
denotes reply)Expected dialog:
Actual dialog: