-
-
Notifications
You must be signed in to change notification settings - Fork 402
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
Broken interrupt handling when connection is inactive #1478
Comments
Because the `time.sleep` during the disconnect phase, the signal handling is thrown off and a new bot is spawned before the `bot.hasquit` flag can be checked. Add a check at the top of the loop to see if the `hasquit` flag was set during a disconnect. Fixes sopel-irc#1478
Because the `time.sleep` during the disconnect phase, the signal handling is thrown off and a new bot is spawned before the `bot.hasquit` flag can be checked. Add a check at the top of the loop to see if the `hasquit` flag was set during a disconnect. Fixes sopel-irc#1478
I see the fix is "low priority", but it is a straightforward backport to 6.6.x (from CLI back to |
I believe it's because, at this point, the Lines 84 to 86 in f694b5b
bot.hasquit to be set after a signal from another thread.
|
During the development for #1527 (and I have now noticed for Docker containers, as well), I found that more often than not, the triggering the exceptions described above ( This docker behavior is not new, but since it's related to this, I figured I would mention it. |
Because the `time.sleep` during the disconnect phase, the signal handling is thrown off and a new bot is spawned before the `bot.hasquit` flag can be checked. Add a check at the top of the loop to see if the `hasquit` flag was set during a disconnect. Fixes sopel-irc#1478
The broken cases described here are fixed in #1534 (and presumably in #1527 also, on the new "run" CLI, though I haven't specifically tested that yet). As @HumorBaby and I pinned down on IRC though, fixing the handling of Ctrl-C during the "waiting to reconnect" state revealed another issue: The quit signal isn't processed until after the Fixing that would require a fair bit of refactoring, so it's a separate issue. In fact, I'll just make one. |
Because the `time.sleep` during the disconnect phase, the signal handling is thrown off and a new bot is spawned before the `bot.hasquit` flag can be checked. Add a check at the top of the loop to see if the `hasquit` flag was set during a disconnect. Fixes sopel-irc#1478
Because of the `time.sleep` during the disconnect phase, the signal handling is thrown off and a new bot is spawned before the `bot.hasquit` flag can be checked. Add a check at the top of the loop to see if the `hasquit` flag was set during a disconnect. Fixes sopel-irc#1478. Reapplied because of changes from sopel-irc#1493.
For the record, I'm testing on macOS today because that's what I have available. However, the same behavior occurs with identical or similar tracebacks on my Ubuntu machine at home, so I don't think it's related to the fact that I'm using Homebrew Python or anything. It's probably related to Sopel's sometimes-wonky exception handling.
Here's what I did:
sopel
sopel
againInterrupting the connection phase resulted in an
AttributeError
, probably as expected (since quitting tries to send something to the socket, and the socket object doesn't exist before connecting finishes):Interrupting the reconnect delay yields a completely different traceback, and additionally requires pressing Ctrl-C twice:
I've run into this second issue relatively often while testing things in the last few months, since I often intentionally interrupt Sopel during states other than "Connected to network and running normally".
The exception itself isn't a big deal (though it would be nice not to spit it out). I consider needing to press Ctrl-C twice to be the main bug here. That simply shouldn't be required.
Interrupting Sopel after the "Loading modules..." line (but before it starts to connect) yields a clean exit, though. That's kind of weird, and I haven't had time to look into why.
Since I know we have a few people digging around in Sopel's internals and refactoring things now (and doing damn good work, too!), I'm hoping one of them will look into this at some point. 😹
This isn't a high-severity bug, but I do want to get it fixed if possible, ideally in the next year or two. That need to press Ctrl-C twice carries over into, for example,
sopel --quit
. Sopel should never need to be told to quit twice, unless something is catastrophically wrong—and waiting to reconnect is a totally normal situation that shouldn't break things the way it does now.The text was updated successfully, but these errors were encountered: