Clarification requested: native connection cleanup, pooling shutdown, and Linux wheel compatibility in mssql-python 1.15.0

[vsatya25]

Hello Microsoft mssql-python maintainers,

We are evaluating mssql-python for an enterprise metadata-management application that performs read-only SQL Server and Azure SQL Database metadata scans in background workers.

Our evaluation baseline is:

Python: CPython 3.13

Platform: Linux x86-64

mssql-python==1.15.0

mssql-python-odbc==18.6.2.1

Our static code review and offline synthetic lifecycle assessments identified several areas requiring clarification before we can approve the driver for production use. These are qualification concerns; we are not claiming that every scenario has been reproduced against a live database.

1. Connection close and native cleanup

If native cleanup fails during Connection.close(), can the Python connection become marked closed even though native resources remain allocated?

What guarantees exist for detecting such failures, preventing unsafe reuse, and completing cleanup during process termination?

2. Disabling connection pooling

If pooling is disabled before the first connection, does that guarantee that no persistent native connection pool or background pooling resources will be created?

Are there supported diagnostics or tests to verify complete native resource cleanup? We reviewed historical issue #267.

3. Cancellation, threading, and shutdown

What are the supported guarantees for canceling an in-flight operation, closing connections during shutdown, and handling a blocked native operation?

Is a dedicated subprocess with pooling disabled a supported isolation strategy for this driver?

4. Diagnostic confidentiality

During cancellation and cleanup failures, what guarantees prevent credentials, access tokens, or connection-string secrets from appearing in exceptions or native diagnostics?

5. Linux binary compatibility

Static inspection of the CPython 3.13 Linux x86-64 wheel suggests that its bundled Rust core requires GLIBC_2.34, despite the wheel's manylinux_2_28 tag.

Can you confirm the supported minimum GLIBC version for this exact release and whether a packaging correction is planned? We also reviewed issue #619, which concerns a different wheel/version/platform combination.

6. Supported release or future fix

Are any of these limitations already resolved in another release, documented elsewhere, or scheduled for a future release?

We would appreciate references to the applicable implementation contracts, documentation, fixes, or tracked issues.

We can provide a minimized, sanitized reproduction and artifact details where useful.

Thank you for your guidance.