-
Notifications
You must be signed in to change notification settings - Fork 701
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
Enable auto reconnection #254
Conversation
This doesn't work at all due to a bug in irc-framework. It just hangs in the registration phase and eventually timeout and try again. I don't understand that part of the irc-framework part as the code is hard to follow, but it sounds like there's some state tracking that needs to be reset that isn't. |
Hey guys, do you think there is a fix in progress on the irc-framework side of things? |
It was fixed recently in irc-fw master, but I haven't had the occasion to retest it yet. But in theory yes, it's fixed! |
Exciting! Can't wait to try this! |
This is ready to be merged, @thelounge/maintainers. |
Well, the code looks good. I'm happy to test it if you still think it needs some testing, equally I'm happy for it to go in (Especially as we'll be releasing to a beta/rc first). So 👍 for it. Obviously the testing is quite awkward trying to get it to disconnect from something to reconnect (Especially as I use znc). |
network.channels[0].pushMessage(client, new Msg({ | ||
text: "Disconnected from the network." | ||
text: "Disconnected from the network, and will not reconnect." |
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.
Is there any addition reason
or something we can give to the user? It seems very frustrating otherwise.
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.
Previous messages in log should give context (e.g. failed reconnects).
I'll test this very soon! |
@@ -1,8 +1,24 @@ | |||
var Msg = require("./models/msg"); |
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.
This doesn't work and crash on start. Needs changing to ../../models/msg
.
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.
Indeed, see https://github.com/thelounge/lounge/blob/xpaw/auto-rc/src/plugins/inputs/query.js#L3.
Fixed in b9a0ee0.
Just tested this, and it finally works! 🎉 The only thing I see that needs fixing would be the comment I just added because it crashes on start, and then I think we're finally good to ship this! |
@maxpoulin64, fixed the issued you noticed in this PR. |
Thanks @astorije, unsure how I missed that. |
It's actually fairly hard to get disconnected from Freenode on purpose! I don't know what black magic is that, but when running The Lounge locally, turning wifi, turning it on a minute or 2 later and refreshing the page, messages posted during the time off wifi appeared, even though the server was running locally. Can't explain this too well, and it might be the consequence of a few things together (IRCv3, irc-fw, some flags on Freenode, I don't know...). However, on a network that is not that smart, I got: The socket error is when I shut down wifi. What this shows is that when reconnecting, it tried with the same username as before, but since the nick has not quit properly, it was still hanging around and the server refused to connect properly. Is there something that can be done here, such as trying with a different nick (old_nik+random_int)? Or is letting the reconnect fail until it succeeds good enough? |
Remember when we argued about nick changes before? It currently only tries to change the name if it's |
Yeah, definitely not an obvious fix. |
Enable auto reconnection
🎉 irc-fw has prepared us for this moment! Closes #18.
We should be reconnecting just fine without any problems. Client already prints all the necessary messages (connecting, reconnecting, socket errors, etc). Server prevents you from sending commands while you are not connected.