Login fails with "Failed to receive token during login response parsing" when the password contains a non-ASCII character (fixed on main by #38, unreleased) #51

Summary

With v1.0.0-beta.3, connecting fails with:

SQL Server driver failure: Protocol Error: Failed to receive token during login response parsing.

whenever the SQL login's password contains a non-ASCII character (here one character outside ASCII, e.g. ö). The cause is a malformed LOGIN7 packet in the bundled mssql-tds preview, which is already fixed upstream and already on main here (#38). The fix just isn't in a release yet. Could you cut one?

Environment

• Tabularis 0.29.0, macOS (arm64)
• SQL Server plugin v1.0.0-beta.3 (mssql-tiberius-bridge 0.1.0-preview.5, mssql-tds-preview 0.1.0-preview.1)
• Microsoft SQL Server 2022 (RTM-CU25) 16.0.4255.1, SQL authentication

Steps to reproduce

1. Create a SQL login whose password contains a non-ASCII character.
2. Add a SQL Server connection in Tabularis with that login.
3. Test the connection. It fails with the error above, for every ssl_mode (disable, preferred, require) and every database (including master).

The same login connects fine with sqlcmd (ODBC Driver 18).

What happens

• Driver side: with tracing enabled, the bundled driver logs the error it collapses into that message: ConnectionClosed("Connection closed by server while reading TDS packet header"). That comes right after PRELOGIN succeeds and LOGIN7 is sent.
• Server side: the connectivity ring buffer (sys.dm_os_ring_buffers, RING_BUFFER_CONNECTIVITY) records each attempt as error 17832, state 9: "The login packet used to open the connection is structurally invalid; the connection has been closed."

That matches microsoft/mssql-rs#425 ("Fix LOGIN7 Unicode lengths", merged 2026-08-30). Before that fix, LOGIN7 field lengths were written as bytes rather than UTF-16 code units, so any non-ASCII username, password, database or app name produced an invalid packet.

Verified fix

I ran a minimal program (Client::connect + SELECT @@VERSION) against the same server and login:

main already moved to bridge 0.2.0 in #38, so a release from main should fix this for anyone with a non-ASCII password.

Side note

The real cause is only visible with a tracing subscriber, which the plugin doesn't install, so users see the generic message. Forwarding mssql-tds's ERROR-level events to the plugin's log, or adding the underlying error to the returned message, would have made this a one-minute diagnosis.