Giuseppe

> Has the operator reconciled in that time? I would expect it didn't execute another reconciliation loop in this case. IIRC operator reports in logs that nothing to reconcile was...

I am indeed running that version of the operator; perhaps there is a cached status issue at play? I'll come back here once I reproduce it.

I think that operator might have detected the problem but was desisting to do any change because cluster was unhealthy, which in turn was caused by clients using the incorrect...

While I wait to reproduce this issue anew, I have been looking at the logs I have about the last time this issue happened. Both those 2 theories I mentioned...

Thanks for your reply! I am attaching here the logs of a recent reproduction of this issue, in case they can shed some light. Notes: 1. I attached logs starting...

Yesterday I found another instance of this problem, but it was slightly different: * all 3 connection strings in the Kubernetes `FoundationDBCluster` `status` were the same * they were all...

> What do you mean by unhealthy? The cluster was not reachable? If you fetch the status in JSON format, it's a boolean field under `.client.database_status.healthy`; it goes to `false`...

These are the logs from that other instance. I can see a single failure to update status in there. Perhaps that's the problem, that if it fails that time, it...

> Where are you running that `fdbcli` command? `\xff\xff/connection_string` will show the current content of the connection string (not necessary the connection string from the DB). Thanks, will take note...

@johscheuer I have one question about the configmap usage: if client connects via `OpenWithConnectionString` using the operator-provided configmap clusterfile content, shall the client re-do the connection when such configmap is...