bug(snowflake): connection properties accumulate or fail on reconnect #2675

Environment

Chat2DB Edition

Chat2DB Community

Chat2DB Version

be8be02 (source build)

Deployment

Web

Operating System

Windows

Operating System Version

Windows 11 10.0.26200

Database and Version

Snowflake JDBC; the defect is in local connection-property assembly and was reproduced with a capturing JDBC driver without a live service.

Problem and Reproduction

Problem Summary

SnowflakeDBManager.getConnection mutates ConnectInfo.extendInfo in place. A null or immutable list fails before connection, while reconnecting with a mutable list repeatedly appends Snowflake-managed properties and can also hide DriverConfig fallback properties.

Steps to Reproduce

1. Create a Snowflake ConnectInfo with database/schema values and extendInfo set to null, List.of(), or a mutable property list.
2. Configure DriverConfig fallback properties such as warehouse and role.
3. Call SnowflakeDBManager.getConnection using a capturing JDBC driver.
4. For the mutable case, call it again with the same ConnectInfo and inspect extendInfo.

Expected Behavior

Connection properties are assembled from a mutable copy, DriverConfig fallback values are preserved, and db, schema, and JDBC_QUERY_RESULT_FORMAT each occur once with current values on every reconnect.

Actual Behavior

Null input throws NullPointerException, immutable input throws UnsupportedOperationException, and mutable input accumulates duplicate managed properties on reconnect. Adding the first managed property also prevents the normal DriverConfig fallback from being used.

Evidence

Logs

Focused regression: SnowflakeDBManagerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

Screenshots or Additional Context

Fork validation PR: HandSonic#28. The tests use a capturing JDBC driver and verify the exact properties passed to a new connection as well as reconnect idempotency.

Impact and Workaround

Impact

Degrades a core workflow. Connection creation can fail for valid configuration shapes, and repeated reconnects can send stale or duplicate JDBC properties.

Workaround

A partial workaround exists: callers can prebuild a mutable explicit property list and avoid reusing ConnectInfo across reconnects.

Submission Checklist

• I reproduced this on the selected Chat2DB edition.
• I searched existing issues for duplicates.
• I removed credentials and private data.