Chat2DB 5.3.6’s quiet fixes matter more than its import features

Chat2DB 5.3.6 is presented as a usability release: import previews, column mapping, configurable CSV parsing, MySQL transaction inspection and better execution-history filtering. For teams that run the open-source database client against production systems, however, the two most consequential changes sit near the bottom of the fix list: one removes SSH credentials from error logs, and the other changes a state-changing API call from GET parameters to a POST JSON body.

Patch the logging path first

The v5.3.6 release notes say SSH connection-error logs no longer include passwords, private-key passphrases or key-file fields. The linked pull request explains the failure path more precisely: when SSH or port-forwarding failed, SSHManager.getSSHSession logged ssh.toString(), while Lombok’s generated representation of SSHInfo included password, passphrase and key-file values.

The patch replaces that generated representation with a manual toString() that omits those three fields while retaining diagnostic connection details such as host, port, user and forwarding information. This is a narrow change, but it changes the upgrade priority for any team that forwards Chat2DB logs into shared support bundles or centralized observability systems. The source does not claim that credentials were exploited; it establishes that connection failures could write them to logs before the patch.

One API client change is required

The same release changes the connection-close endpoint from a GET request with query parameters to POST /api/connection/close with a JSON request body. Chat2DB explicitly tells API clients that call the endpoint to update their requests.

The implementation review says the controller now accepts the existing validated close-request object and delegates to unchanged connection-pool logic. It also records the validation performed before merge: one controller test, 10 connection-pool tests, a 48-module backend package, frontend lint/prebuild/build checks and real HTTP and SQL Server session checks. In those checks, GET requests and invalid bodies did not close sessions, while a valid POST closed only the selected datasource; repeated close and reconnect remained usable. Desktop JCEF transport was inspected statically rather than tested in a desktop runtime, an explicit remaining boundary.

The visible features are still useful

For day-to-day database work, v5.3.6 adds CSV and Excel previews and column mapping on web and desktop, plus controls for encoding, delimiters, row ranges and date or decimal formats. MySQL 5.7 and 8.0 users can inspect active InnoDB transactions, duration, SQL, lock waits and blocking connections, with explicit messages for unavailable metadata or insufficient privileges. Execution history can be filtered by datasource, database and schema and searched by SQL keyword.

The practical rollout order is therefore straightforward: upgrade to stop exposing SSH secrets through the documented error path, update integrations that call the close endpoint, then validate the new import and transaction-inspection workflows under the same database privileges used in production. That prioritization follows the release’s verified behavioral changes rather than its headline feature list.