MSSQL connector reports "unsupported version" when backend can't be contacted

[sgnn7]

Summary

When the broker uses the mssql connector and you misconfigure the host/port in secretless.yml, connections through the broker will show a misleading error like this:

Error: Microsoft ODBC Driver 17 for SQL Server : ODBC Driver 17 for SQL Server does not support connections to SQL Server 2000 or earlier versions.

Steps to Reproduce

• Start mssql container:

docker run -it -p 2433:1433 -e SA_PASSWORD="yourStrong()Password" -e ACCEPT_EULA=Y mcr.microsoft.com/mssql/server:2017-latest

• Create secretless.yml:

version: 2
services:
  mssql:
    connector: mssql
    listenOn: tcp://0.0.0.0:3433
    credentials:
      username: sa
      password: yourStrong()Password
      host: 127.0.0.1
      port: 5555

• Run secretless with this config
• Connect to the DB with something like this:

sqlcmd -S 127.0.0.1,3433 -U dummy -P dummy -d master -Q "select @@version;"

Expected Results

Error that indicates that connection cannot be made

Actual Results (including error logs, if applicable)

Unsupported driver version error

[izgeri]

@sgnn7 did you end up looking at this issue any further? wondering if we did some work to address this, or if it's an outstanding bug.

[sgnn7]

@izgeri I think it's an outstanding bug still but @doodlesbykumbi can confirm

[doodlesbykumbi]

@izgeri @sgnn7

It is outstanding. It's not clear at the moment what is the best way to convey this error to the client is.

In a normal client server scenario, the client calls server, releases server doesn't exist, issues a client-side idiosyncratic error

With Secretless, the client calls Secretless. Secretless is available and so we've already lost the idiosyncratic errors. Now all we have to rely on are server side errors. This wouldn't be a problem normally but a challenge arises because of the MSSQL handshake.

1. client sends prelogin request
2. server responds to prelogin request, or error. HOWEVER, any error error results in the client assuming that its just because the server doesn't support this client.
3. client sends login request
4. server send login response, or error.

In Secretless, we only find out about the target not being available at (1). Which means if we send an error at (2) we get the behaviour we're seeing here.

Something we could try is have Secretless fake (2), receive and discard (3) then send the error in (4).