Migrating a Postgres or MySQL notify config disables all bucket notifications

[Vonng]

Expected Behavior

Migrating a pre-KV configuration that has a Postgres or MySQL notification target should produce a configuration that loads.

Current Behavior

It produces one that is rejected, and the rejection takes every other notification target down with it.

SetNotifyPostgres and SetNotifyMySQL (internal/config/notify/legacy.go), the migration helpers called from cmd/config-migrate.go, write five keys — host, port, username, password, database — that neither DefaultPostgresKVS nor DefaultMySQLKVS registered, and that GetNotifyPostgres / GetNotifyMySQL never read.

Config.CheckValidKeys matches on key name and ignores the value, so this is not limited to configurations that used the discrete-field form. A target migrated from the connection-string form carries the same five keys written empty, and is rejected identically.

The blast radius is the part worth emphasising. FetchEnabledTargets returns on the first failing sub-system, so a single migrated Postgres target disables all bucket notifications — webhook, Kafka, NATS, everything — with a single log line naming only the Postgres sub-system.

Separately, password here is a plaintext database password. Because the key was unregistered it carried no Sensitive flag, so it was written verbatim into health and diagnostic bundles rather than redacted.

Steps to Reproduce

1. Start from a pre-KV config with notify_postgres (or notify_mysql) enabled, in either the connection-string or the discrete-field form.
2. Start a server that performs the config migration.
3. Restart. Bucket notifications are gone; the log names only the Postgres or MySQL sub-system.

Resolution

Fixed in 6cb6fa90c, shipping in the next release.

Three of the four links this needed were already present: the struct fields, Validate() accepting the discrete form as an alternative to the connection string, and both NewPostgreSQLTarget and NewMySQLTarget assembling a connection string from those fields when the string one is empty. Even the environment-variable names were declared. Only the registration and the read were missing, so the fix completes that wiring rather than adding a configuration form — nothing that worked before changes, and password now carries a Sensitive flag and is redacted.

One defect was uncovered on the newly reachable path and fixed with it: the Postgres assembly emitted username=, while libpq's keyword is user=, which a server rejects as an unrecognized configuration parameter. The MySQL side has no equivalent problem — it builds its DSN through mysql.Config.FormatDSN.

The source-level audit added for #39 now has an empty knownUnregisteredWrites; these ten entries were the last of it.

[Vonng]

Fixed in 6cb6fa90c, shipping in the next release. Regression coverage drives the real migration helpers end to end: both forms round-trip through CheckValidKeys and GetNotify*, and all three new tests fail against the unfixed tree with found invalid keys (host, port, username, password, database).

[Vonng]

Reopening: the fix was reverted in 2ffb53abf and this defect is unfixed again.

Registering host, port, username, password and database as config keys is what made CheckValidKeys accept a migrated target — but it also broke the connection-string form of configuring Postgres notifications, which is the form the help text gives as its example. kvFields tokenizes mc admin config set input by searching for registered key names with strings.Index, anywhere in the string and with no awareness of quoting, so once port was registered the port= inside connection_string="host=db port=5432 dbname=x" became a split point and the command failed with invalid port. Confirmed by building the parent commit and running the same command against both binaries: the older one accepts the string and dials, the newer one does not.

The two requirements are mutually exclusive by construction. CheckValidKeys accepts the migrated config only if the keys are registered, and kvFields splits on exactly the registered keys, so making the migration load necessarily breaks the connection string. Registration is not a viable approach.

The fix that does not collide is the other branch considered at the time: have SetNotifyPostgres and SetNotifyMySQL synthesize a connection string (connection_string, and dsn_string via mysql.Config.FormatDSN) and stop writing the discrete keys at all. No new key names, so nothing to collide with.

Two things from the reverted work were kept, since they are correct however the fields are populated: libpq's keyword is user rather than username, and connection parameters need single-quoting — an unquoted value containing a space breaks the parse, and one containing host= appends a parameter the config never named.

[Vonng]

Status and plan: the reverted fix registered the five legacy keys, which made CheckValidKeys accept migrated targets but broke the connection-string form — the configuration path the help text documents. The durable fix belongs on the migration side instead: SetNotifyPostgres/SetNotifyMySQL should stop emitting (or should strip) the discrete keys that no current KVS registers, so both forms round-trip cleanly. Scheduled for an early follow-up release after RELEASE.2026-08-06, alongside the multipart-checksum conformance batch (#46). Scope note: only pre-KV (config.json-era) configurations reach this migration path.