SASL authentication prompts seem to block the entire program, which can result in losing all IRC connections if the prompts block for an extended period of time (more than a couple minutes).
For some testing, I have a connection set up to a server with it set to not save passwords, so I need to enter my password for SASL authentication each time.
If the connection drops for whatever reason, Ambassador will try to reconnect automatically. The password dialog will come up prompting for credentials. When this happens, it appears that normal processing for PING requests from IRC servers is suspended. As a result, if it takes more than a couple minutes for the user to notice the reconnect and re-enter credentials, all IRC connections are dropped because the server closes them due to ping timeout.
I just happened to notice this as I'm debugging intermittent connectivity issues with a particular IRC server. If that connection drops and I don't re-enter my password within 2 minutes, then Ambassador will fail to respond to any PING replies from all networks, and it will drop all of my IRC connections. Furthermore, this isn't apparent until the prompt is dismissed (password entered) - at which point the GUI updates to show that a ping timeout occurred, possibly even several minutes ago. For example:
I haven't looked at any code, so I don't know how easy this is to fix, but it seems like a major design deficiency to have an authentication prompt blocking normal automated functions of the program. Since the GUI also doesn't update until the prompt is resolved, it seems like certain things might not be getting processed somewhere in Ambassador while the prompt is blocking. Maybe this should be handled by a separate thread? The authentication prompt is for a completed separate IRC network. It shouldn't be blocking PING responses at all, and certainly not for an unrelated connection.
Then again, the timestamp for the ping timeout in the screenshot above appears correct. This suggests that Ambassador is still receiving messages and timestamping them while the prompt is blocking, but for whatever reason, it's not responding to pings.
I'm not hopeful this will be resolved soon since it seems like Ambassador is abandoned software now, but wanted to note this in case it can be looked at in the future.
SASL authentication prompts seem to block the entire program, which can result in losing all IRC connections if the prompts block for an extended period of time (more than a couple minutes).
For some testing, I have a connection set up to a server with it set to not save passwords, so I need to enter my password for SASL authentication each time.
If the connection drops for whatever reason, Ambassador will try to reconnect automatically. The password dialog will come up prompting for credentials. When this happens, it appears that normal processing for PING requests from IRC servers is suspended. As a result, if it takes more than a couple minutes for the user to notice the reconnect and re-enter credentials, all IRC connections are dropped because the server closes them due to ping timeout.
I just happened to notice this as I'm debugging intermittent connectivity issues with a particular IRC server. If that connection drops and I don't re-enter my password within 2 minutes, then Ambassador will fail to respond to any
PINGreplies from all networks, and it will drop all of my IRC connections. Furthermore, this isn't apparent until the prompt is dismissed (password entered) - at which point the GUI updates to show that a ping timeout occurred, possibly even several minutes ago. For example:I haven't looked at any code, so I don't know how easy this is to fix, but it seems like a major design deficiency to have an authentication prompt blocking normal automated functions of the program. Since the GUI also doesn't update until the prompt is resolved, it seems like certain things might not be getting processed somewhere in Ambassador while the prompt is blocking. Maybe this should be handled by a separate thread? The authentication prompt is for a completed separate IRC network. It shouldn't be blocking PING responses at all, and certainly not for an unrelated connection.
Then again, the timestamp for the ping timeout in the screenshot above appears correct. This suggests that Ambassador is still receiving messages and timestamping them while the prompt is blocking, but for whatever reason, it's not responding to pings.
I'm not hopeful this will be resolved soon since it seems like Ambassador is abandoned software now, but wanted to note this in case it can be looked at in the future.