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
Fix write connection reconnection issues #2850
Conversation
big if true |
huge if factual |
enormous if accurate |
sizeable if veracious |
Chatterino currently does not handle disconnects of the write connection, which causes messages to remain buffered until you manually reconnect, after which it will send all messages at once. This patch addresses the lack of reconnection specifically, and attempts to refactor some of the reconnection logic to make it more robust. Backoff behavior is introduced to *both* read/write cons to avoid reconnection loops. To replicate the issue, simply lose your (write) connection to TMI. This can be "simulated" using something like: tcpkill -i eth0 host 44.226.36.141 or host 34.217.198.238 or host 100.20.159.232 An alternative/secondary approach would be to detect failures of the underlying `sendRaw` method (as it returns false if the message can't be sent to the connection), but better monitoring of the connection state should be sufficient. The way the code is setup currently doesn't really make it easy to implement this "cleanly". E.g. calls `initializeConnection` are skipped on reconnect, but since we're reconnecting with the same parameters, this should have little actual consequence.
Account switching (including updating your own OAuth token) doesn't work properly, because the disconnect triggered by Working on a fix. |
This avoids reconnect behavior when e.g. switching / updating accounts.
Co-authored-by: Felanbird <41973452+Felanbird@users.noreply.github.com>
The behavior should be OK now. (Also shouldn't have force pushed a formatting mistake, oops.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me - I'm fine to merge this in pending some comments being added/expanded upon
Thanks a lot for looking into this!
Avoids an already running pingTimer being called early in the connection and ensures we're always in a sensible state when opening a connection. Improve comments as requested.
Shuffled some state resets around and improved the comments. Let me know if that's sufficient. |
Perfect, thank you. I'll merge this into master and have people take this for a spin in the nightly version! |
Now we're on commit 2f568b8; Changes from upstream we pulled: - Minor: Searching for users in the viewer list now searches anywhere in the user's name. (Chatterino#2861) - Minor: Now shows deletions of messages like timeouts (Chatterino#1155, Chatterino#2841) - Minor: Added a link to accounts page in settings to "You need to be logged in to send messages" message. (Chatterino#2862) - Minor: Switch to Twitch v2 emote API for animated emote support. (Chatterino#2863) - Bugfix: Fix reconnecting when IRC write connection is lost (Chatterino#1831, Chatterino#2356, Chatterino#2850) - Bugfix: Fixed bit emotes not loading in some rare cases. (Chatterino#2856)
Now we're on commit 0021290; Changes from upstream we pulled: - Bugfix: Fix reconnecting when IRC write connection is lost (Chatterino#1831, Chatterino#2356, Chatterino#2850, Chatterino#2892) - Bugfix: Fixed subscription emotes showing up incorrectly in the emote menu. (Chatterino#2905) Changes added in Chatterino7 only: - Major: Added 7tv badges. (2154981) - Minor: Fixed potential issues preventing 7tv emotes from loading (c0b1117)
Ready for review/feedback. There's a lot of room for (additional) refactoring on the connection logic, but I figured I'd at least fix the issue first.
Pull request checklist:
CHANGELOG.md
was updated, if applicableDescription
Chatterino currently does not handle disconnects of the write connection, which
causes messages to remain buffered until you manually reconnect, after which it
will send all messages at once.
This patch addresses the lack of reconnection specifically, and attempts to
refactor some of the reconnection logic to make it more robust. Backoff behavior
is introduced to both read/write cons to avoid reconnection loops.
To replicate the issue, simply lose your (write) connection to TMI. This can be
"simulated" using something like:
An alternative/secondary approach would be to detect failures of the underlying
sendRaw
method (as it returns false if the message can't be sent to theconnection), but better monitoring of the connection state should be sufficient.
The way the code is setup currently doesn't really make it easy to implement
this "cleanly". E.g. calls
initializeConnection
are skipped on reconnect, butsince we're reconnecting with the same parameters, this should have little
actual consequence.