RadiatorDB node setup failed

Logged when a configured RadiatorDB node fails provisioning or a previous interrupted attempt is detected. The node remains outside request routing and requires destructive cleanup before reprovisioning. The attached error includes the underlying PostgreSQL or connection cause. Setup also fails when the node has completed setup but does not store a configured collection that other nodes store documents in, for example after a Destroy Collection that did not finish on every node; the error names the collection and those nodes, and reprovisioning copies the collection from them.

When replication setup fails, setup_step names the step that was running, peers_completed and peers_total show how many existing nodes were already connected, and elapsed_ms, setup_timeout_ms, and edge_started_after_ms show how the setup budget was used. For a failed replication direction, subscriber and publisher name the nodes, publisher_replication_host and publisher_replication_port give the address the subscriber's PostgreSQL server connects to, and subscription_state, relation_states, sync_workers, workers_waiting_for_lock, sync_error_count, apply_error_count, and publisher_slot describe PostgreSQL logical replication when setup stopped.

Fix the cause, then remove the node and reprovision it after cleanup completes. If setup_step is subscription_creation or publisher_slot is missing or inactive, check that the subscriber's PostgreSQL server can reach publisher_replication_host and publisher_replication_port and that pg_hba.conf on the publisher allows publisher_replication_user. If setup_step is existing_subscription_reuse, Radiator could not verify a subscription left by an earlier setup; check that Radiator can reach the publisher address in the error with the configured RadiatorDB credentials. If setup_step is initial_sync, check sync_error_count, apply_error_count, and the subscriber's PostgreSQL server log; if relations are still copying without errors, increase setup_timeout. A non-zero workers_waiting_for_lock points to long-running transactions on the subscriber.