Running query in one window/tabs checks for connectivity status of other windows/tabs

[gms8994]

• Sequel Ace Version: 2.1.5
• macOS Version: 10.15.5
• MySQL Version: N/A

Description
Running a query against a local server first checks the connected status of remote servers, which may require closing the tabs before continuing (potentially losing user generated queries).

Steps To Reproduce

1. Connect to a remote server and run some queries.
2. In another tab, connect to a local server and run some queries.
3. Disconnect your network connection and try to run queries in the local server window. (It may take a minute before Sequel Ace makes this determination).
4. You'll be prevented from doing so until a check for connectivity for the remote server completes (and subsequently fails and requires you to close the tab).

Expected Behaviour
Don't check a background tab connection status, so the tab won't need to be closed. It's a

Is Issue Present in Latest Beta?
N/A

[gms8994]

This may not be the running of the query that triggers it, but perhaps just a status bar notification that the connection is gone instead of stealing focus and forcing a close (perhaps reconnect isn't possible)?

[jamesstout]

I can't reproduce this, I can run the local query, until after a minute or so, I get a prompt saying the remote server connection was lost and I need to [dis|re]connect.

remote: maria 10.4.13
local: 8.0.21

I'll look at the connection code though..

[jamesstout]

Might be related to updating the query history. The first thing it does is check if it's connected...

- (void)historyItemsHaveBeenUpdated:(NSNotification *)notification
{
	// Abort if the connection has been closed already - sign of a closed window
	if (![mySQLConnection isConnected]) return;

- (BOOL)isConnected
{
	// If the connection has been allowed to drop in the background, restore it if posslbe
	if (state == SPMySQLConnectionLostInBackground) {
		[self _reconnectAllowingRetries:YES];
	}

	return (state == SPMySQLConnected || state == SPMySQLDisconnecting);
}

_reconnectAllowingRetries waits 10 seconds, tries to reconnect, then displays the dialog. Still unsure why it's checking the other tab though.

[jamesstout]

No, it's the _keepAlive timer. If no connection, calls _reconnectAfterBackgroundConnectionLoss which calls _reconnectAllowingRetries, which if all connection attempts fail, calls _delegateDecisionForLostConnection which prompts the user to [re|dis]connect.

The timer runs on all connections.

[Jason-Morcos]

@jamesstout So is this a bug or should we close this issue or what? I'm a little confused what the next step is here! :)

[jamesstout]

Not entirely sure it's a bug. We could as @gms8994 suggests add this feature:

perhaps just a status bar notification that the connection is gone instead of stealing focus and forcing a close (perhaps reconnect isn't possible)?

[Iv4nS]

This is a really big issue in my workflow, I've encountered many times and I always loose my entire tab if I'm unable to reconnect to the server.

[samuelbradshaw]

I've run into this as well; it would be nice if there were a way to indicate that it's disconnected without blocking the user and closing the tab, so anything you're currently working on in that tab can be copied to somewhere else before closing. A note in the status bar would be good, but I'm not sure if it's visible enough that the user will understand what's happening when they come back to the tab but then can't do anything. I'm not sure what the best UX would be.

[Iv4nS]

I agree, the best scenario would be to leave it disconnected somehow with an indicator, maybe graying out at all the tables and database selection, with only the queries tab visible and allow reconnection later on when the user decides to (if ever).

Another solution I've thought that it would at least make things somewhat better (if the tab really can't live without the connection) would be to have a button in that same dialog to either save the queries to a file or to the clipboard.

[Iv4nS]

I would actually classify it as a bug. A very bad analogy would be: You have a browser opened with multiple tabs, one of them mysite.com and another coolsite.com, you are doing things on the coolsite.com tab and for some reason the server hosting mysite.com goes down then your browser forces you back to mysite.com and to either refresh until the server is back or entirely close that tab.

[indreka]

Can confirm that when connecting to different VPN and while leaving old query window/tab open and then trying to run query in some other window/tab, the previous window/tab steals focus and complains about connection loss and gives only 2 options: reconnect or close
While being in a different VPN, reconnect is not an option and closing the window/tab means losing previous state so it is also not an option actually. Having a "Cancel" there would improve situation.

Checking all tabs/windows connection when doing a query in only ONE should be definitely classified as a bug not to mention a big overhead with many windows open.

[FaimMedia]

Same problem here, very annoying, if a connection in an other tab is lost, Sequel will hang for like 30 secondes before responding and popping up a message. Even when using a different tab.

[n9yty]

Still happening to me somewhat regularly, especially with remote connections over ssh, if I leave a window open and come back later, sometimes not even realizing I had an old window, opening a new one, and then things become unresponsive as it complains about the lost connection. There should be a graceful recovery in case a connection is lost, I have tried using "reconnect" many times but it never does and eventually the only way out is to close windows and lose the query.

[Kaspik]

This might be resolved now in 3.3.0. Closing, let us know if it's still an issue!

[indreka]

This is still not resolved after latest update, the issue is not tab specific, you should be able to reproduce with 2 windows open (both having only one tab).

It should be quite easy to verify:
assuming you have kubernetes and/or docker, run two instances of mysql databases on different ports
In sequel ace, open two connections, one to each database.
Close one of the mysql instances while keeping the other running.
Wait at least 30 minutes, try to run query in a window that was opened to the server that is still running.
Other window (connected to the closed mysql instance) pops info focus and keeps nagging about closing the connection or reconnecting.

Can this issue be reopened and perhaps title changed from
Running query in one tab checks for connectivity status of other tabs
to
Running query in one window/tabs checks for connectivity status of other windows/tabs
The issue is not at all Tab related.

[Kaspik]

Okay, then it's not related to tabbing but to not closing the connections actually - which is duplicate of #811

[indreka]

Umm, are you 100% sure? #811 describes issue that connection remains open even when closing a window/tab, which means it is not relevant to this issue at all.

In the case that I described (and everyone else in this issue have described) the windows/tabs are all open, no one is trying to close anything on their own. Please read the previous comment more thoroughly. I'm talking about actual mysql server instances going away in the background, not sequel ace instances, they are not the same...

[Kaspik]

Hmm, okay, I read "Close one of the mysql instances while keeping the other running." as close the Sequel Ace instance.

Sounds like it's a mix of #811, #658 and slightly #345 - the connections are not managed properly right now under some circumstances (computer sleep, memory pressure, ...). Reconnection is problematic and is also a blocker due to not being able to reconnect. Big refactoring is on our roadmap, the tabbing / windows was a first step.

[indreka]

Ok, thanks for reopening the issue, will keep updating the status with newer releases :)

[Jason-Morcos]

This should be fixed in the latest beta along with #658! If not, I'll re-open
The fix will be included in release 3.4.1!