Send a usable payload from the Test connection button (#355)

[GermanBluefox]

Fixes #355. "Test connection" reported a failure while the adapter was happily writing to the same database — and the message, "invalid config", sent the reporter looking at settings that were fine.

It is not a database error

The adapter sends that string from exactly one place:

if (!msg?.message?.config) {
    this.sendTo(msg.from, msg.command, { error: 'invalid config' }, msg.callback);

The request arrived with no settings at all. The database is never contacted, which is why everything else kept working.

Why the settings went missing

The payload is a text template, substituted and then parsed by the admin:

try { data = JSON.parse(dataStr); }
catch { console.error(`Cannot parse json data: ${dataStr}`); }
data ??= null;

A parse failure is logged to the browser console only and the message is sent with null. So anything that made the template produce invalid JSON became "invalid config" with no visible explanation.

encrypt and rejectUnauthorized were interpolated without quotes, so an unset checkbox produced "encrypt": undefined. A value containing a newline broke it too — the admin's escapeString() handles quotes and backslashes, but not control characters.

Every value now goes through JSON.stringify, which quotes and escapes it and turns a missing one into a usable literal. Checked against the inputs that used to break:

input	before	now
unset encrypt checkbox	broken	ok
password with "	ok (admin escapes it)	ok
password with \	ok (admin escapes it)	ok
password with a newline	broken	ok
completely empty configuration	broken	ok

Three settings were never sent

testConnection() reads them, the template did not include them:

• doNotCreateDatabase — so the PostgreSQL branch always tested the maintenance database postgres. That is the defect behind Connection to PostgreSQL fails due to relative file paths #285, and PostgreSQL: connect directly to the configured database when told not to create it #562 fixed it in the adapter while the button never sent the flag, so the fix could not take effect. This is what makes it work.
• dbname — the fallback would have used iobroker rather than the configured name.
• dockerMysql — so applyDockerMysqlConfig() never ran in the test path and a containerised instance was tested against whatever stale host and credentials the hidden fields still held. That alone produces exactly the reported shape: test red, operation green.

And the message

It now says what happened — "The test request arrived without a configuration" — instead of blaming the configuration. Translated into all ten languages and registered in the button's error map.

Verification

npm run check:ts, npm run lint (both passes) and prettier --check are clean; 192 unit tests pass. The template was evaluated the way the admin does it (a template literal with data in scope) against each case in the table above, and doNotCreateDatabase: true with dbname: "meine_db" now arrives intact.

One correction to my own first reading: I initially thought quotes and backslashes in a password broke the template. The admin's escapeString() already rewrites those tokens, so that case is covered on current admin versions — it may explain the report on the 2024 version the reporter used, but I cannot verify that. The unquoted booleans, the control characters and the three missing settings are the parts that are demonstrably broken today.

🤖 Generated with Claude Code