[stakach]

Problem

Specs driving real database changes through the changefeed showed three gaps:

• every update reconnected, even a rename: the changed attributes always include updated_at, so no update counted as safe
• an address (or credentials) change to a broker that wasn't reachable yet was never applied: the retry stopped as soon as it saw the old publisher still running
• a broker at a new address was never sent the current state, as only brand new brokers triggered a resync

Events are also processed concurrently, so two quick edits could finish out of order.

Fix

• Apply the Broker as it is in the database now, one change per Broker at a time (per-broker lock)
• Reconnect only when connection settings change (host, port, tls, auth type, username, password, certificate); anything else is applied to the running publisher
• Retry until a publisher is connected with the current settings, not merely until one exists. The old publisher keeps running until the replacement connects
• Republish all state whenever the connection is rebuilt
• mqtt_broker_manager_spec left its manager running, which took over the sessions of later specs (the "stopped and will not reconnect" errors in the suite)

Testing

New spec/publishing/broker_changes_spec.cr: add, password change, rename, unreachable address that comes up later, resync on address change, quick successive edits, delete. Full suite natively: 86 examples, 1 failure (clear_spec, which fails the same way on master when run natively).

🤖 Generated with Claude Code