[Mordris]

Description

For SQL Server errors of severity 20 and above, the mssql and cloud-sql-mssql sources answer with only SQL Server had internal error: no error number, severity or message (#4444).

go-mssqldb returns mssql.ServerError for these errors. Its Error() is that fixed text; the errors the server sent are kept in the mssql.Error it wraps. That error's own fields describe the last error, which is usually a consequence ("the session is in the kill state"); its All field lists every error from first to last, and the first is the cause.

This PR adds mssqlcommon.WithServerErrorDetails, which RunSQL in both sources now applies at its two error returns (the query call and results.Err()). For an mssql.ServerError it appends every entry of All, in order, formatted from its fields, after the existing text, and keeps the original error wrapped, so errors.As still finds it. Every other error is returned unchanged.

RAISERROR('severe error text', 20, 1) WITH LOG through mssql-execute-sql, before and after (SQL Server 2025 CU10):

before: error processing request: unable to execute query: SQL Server had internal error
after:  error processing request: unable to execute query: SQL Server had internal error: severe error text (error 50000, severity 20, state 1); Process ID 89 has raised user error 50000, severity 20. SQL Server is terminating this process. (error 2745, severity 16, state 2); Cannot continue the execution because the session is in the kill state. (error 596, severity 21, state 1)

Design notes:

• The text is built from the fields, not from mssql.Error.Error(), whose format changes in go-mssqldb v1.11 (Collect all error messages for Error.Error() microsoft/go-mssqldb#250, which chore(deps): update go #4246 brings in). The output is the same on v1.10.0 and v1.11.2.
• error is lower case on purpose: util.ProcessGeneralError classifies by Error 401, Error 403 and Error 429, and SQL Server has errors with those numbers. A unit test checks that the category stays AGENT_ERROR.
• The SQL Server had internal error prefix stays, for clients that match on it.
• The helper lives in its own file in internal/tools/mssql/mssqlcommon, following mysqlcommon. fix(source/mssql,source/cloudsqlmssql): return decimal, money and GUID values as text instead of base64 #4284 adds mssqlcommon.go to the same package, so the two merge in either order.

Testing:

• Unit tests for the helper in internal/tools/mssql/mssqlcommon/errors_test.go. mssql.ServerError keeps the wrapped error in an unexported field, so the tests stand in for it with errors.Join(mssql.Error{...}, mssql.ServerError{}).
• The Linux job of tests.yaml (build, both go test -race runs, coverage gate), the go mod tidy check, and golangci-lint v2.15.0 on the changed packages (0 issues), all in a golang:1.27.3 container.
• Coverage: the new mssqlcommon code is at 100%. internal/sources/mssql (8.2%) and internal/sources/cloudsqlmssql (7.9%) are the same as on main; RunSQL, where the two call sites are, is reached only by the integration tests.
• Live, with Toolbox built from this branch with the repository's Dockerfile, against SQL Server 2025 CU10: both error returns (the query call above, and results.Err() via SELECT 1 AS a; RAISERROR(...)) now carry the chain. Severity 16 errors, divide by zero, result sets and multiple result sets are unchanged. The chain the helper formats is the same on SQL Server 2017 CU31, 2019 CU32, 2022 CU27 and 2025 CU10, with go-mssqldb v1.10.0 and v1.11.2 (details in mssql: severe errors (severity 20 and above) lose the server's message: "SQL Server had internal error" #4444).
• No integration test. Raising severity 19 and above WITH LOG needs a login in the sysadmin role or with ALTER TRACE (a plain login gets error 2778), and I don't know whether the CI logins have either. If they do, I can add one to tests/mssql.
• cloud-sql-mssql gets the same change at the same two returns; I couldn't run it against Cloud SQL.

Security:

• No query is built or changed, and no user input reaches SQL.
• The added text is SQL Server's own error messages, which Toolbox already returns for errors below severity 20. No credentials, connection strings or parameters are added.
• No file paths, commands or auth checks are touched.

PR Checklist

• Make sure you reviewed
  CONTRIBUTING.md
• Make sure to open an issue as a
  bug/issue
  before writing your code! That way we can discuss the change, evaluate
  designs, and agree on the general idea
• Ensure you have manually reviewed the entire diff before requesting a
  review
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary): no docs change needed
• Make sure to add ! if this involve a breaking change: not breaking; the existing text stays as the prefix

🛠️ Fixes #4444

[gemini-code-assist]

Code Review

This pull request introduces a common error-handling utility for MSSQL sources to extract and format detailed SQL Server errors from severe database errors, and integrates it into both the Cloud SQL MSSQL and standard MSSQL sources. Feedback on the changes suggests checking the return value of errors.As when extracting the underlying mssql.Error to prevent passing an uninitialized zero-value struct to the formatting function.