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

BasicClient.quit("Message") does not display custom message on quit event. #117

Open
shatteredbeam opened this issue Apr 3, 2019 · 2 comments
Assignees

Comments

@shatteredbeam
Copy link

When using .quit("Some Custom Message") the client disconnects cleanly, but it does not display its quit message, only its own nickname which is usually added by the server, indicating the custom message is not being passed by the method to the server.

@theunkn0wn1 theunkn0wn1 self-assigned this Apr 3, 2019
@theunkn0wn1
Copy link
Collaborator

Am able to reproduce, current theory is there is a race condition during Exit.

What appears to happen is Pydle sends a QUIT message with the correct payload, but then immediately closes its connection with the server.

According to the RFC specification, the server sends an acknowledgement ERROR message in response, which it can't do if pydle closes the link.

Here is a comparison between Pydle (top) and Hexchat(bottom) as seen by Wireshark.
image

@theunkn0wn1
Copy link
Collaborator

To resolve this chicken/egg scenario, We need a way of communicating to pydle.Client.disconnect(expected:bool) that an incoming disconnect is expected, without calling the method itself. In order for the exit message to be properly acknowledged by the IRC server, pydle must remain connected until the server sends back an acknowledgement. Unfortunately this acknowledgement is immediately followed by the server closing the link.

I think a viable approach would be to use an asyncio.Event as a flag, stored in the pydle.Client instance.
When pydle is asked to quit gracefully, it will set this flag and send the quit message to IRC.
When disconnect is inevitably called it can check the state of this flag (as opposed to it being passed as an argument), thus allowing it to treat an incoming disconnect as expected while allowing something else to cause the disconnect.

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

No branches or pull requests

2 participants