QueryContext blocks when the network is down about go-mssqldb HOT 4 OPEN

Is this the same problem as #91?
PR #109 attempts to fix that but is failing all the tests.

from go-mssqldb.

no, not quite the same. I think #91 actually describes expected behaviour, not a bug. After all, Ping() and Query() must block as long as the "pong" is yet to be seen and the TCP connection is still alive (which is usually well after the network cable is disconnected). The solution to issue #91 is "replace Ping by PingContext to avoid the halting problem", I think.

But for PingContext and QueryContext it is different, I would expect for them to abort once the context is done, "no matter what". They shouldn't wait for a slow network. It is the same loop that blocks though. So this present issue (and the identical denisenkom#527) needs some unblocking.

I'm a bit out of my depth. My best lead is this: readCancelConfirmation would need to (receive as a parameter and) consider the context, and stop blocking there. Maybe the connection could just be discarded and closed. Or the incoming tokens up until the cancellation confirmation would have to be consumed in the background.

from go-mssqldb.

Completely untested code below. This acts on

• the context being cancelled,
• new tokens coming in (anything up until a doneStructis discarded),
• or the token channel being closed (after a network error)
• and blocks while neither of the three occurs.

// consume tokens until we get cancellation confirmation, or until context is done
func readCancelConfirmation(ctx context.Context, tokChan chan tokenStruct) bool {
	for {
		select {

		case <-ctx.Done():
			// this should in effect discard the connection. Debatable.
			return false

		case tok, alive := <-tokChan:

			if !alive {
				// tokChan is closed. 
				return false
			}

			confirmToken, isConfirmation := tok.(*doneStruct)
			if isConfirmation && (confirmToken.Status&doneAttn != 0) {
				// got cancellation confirmation, the connection is usable again
				return true
			}
		}
	}
}

Actually it is debatable if QueryContext may discard the connection just because the context is cancelled. It seems to depend on the semantics of "cancelling". For example, in an interactive environment like sqlcmd, the user could say "I see, the query takes too long. Abort this operation, but let me resume with the same connection." They'd have to wait then.

from go-mssqldb.