<@U04S8PLJWMT> Getting these errors in airbyte-ser...
# replication-ask-ai
g
@kapa.ai Getting these errors in airbyte-server logs, any thoughts:
Copy code
i.a.c.t.TemporalUtils(getTemporalClientWhenConnected):184 - Ignoring exception while trying to request Temporal namespace:
io.grpc.StatusRuntimeException: UNAVAILABLE: GetNamespace operation failed. Error no usable database connection found
k
That error means the Airbyte server can’t talk to Temporal because Temporal itself has no working database connection. All the “GetNamespace … no usable database connection found” messages are coming from Temporal, not from Airbyte directly. [Temporal context; Server–Temporal errors] From the similar issues in the knowledge sources, the root causes are typically: 1. Temporal DB unreachable / misconfigured ◦ Wrong host/port/DB/user/password in the Temporal/Postgres env vars. ◦ Network/firewall rules blocking access from the Temporal pod/container to the Postgres instance. ◦ Postgres not listening for external connections or not allowing this user/host. [DNS / DB issues; External DB change] 2. Missing permissions or databases ◦ When using an external Postgres, the Airbyte/Temporal user must be able to access (and sometimes create) the
temporal
and
temporal_visibility
databases, or you must create them and grant privileges manually. [Create temporal DBs] 3. SSL / cloud‑DB specifics ◦ For Azure PostgreSQL, Temporal needed SSL configured correctly before it could connect. [Azure Postgres SSL] 4. Network / region issues ◦ In one EKS case, moving Temporal’s Postgres (RDS) into the same region/VPC as the cluster fixed repeated “context deadline exceeded” / DB connectivity problems. [Temporal context] What to check next 1. Look at the *`airbyte-temporal` logs*; you should see the underlying DB error there (host not found, timeout, auth failure, SSL, etc.). 2. Verify the DB connection settings used by Temporal (env vars / Helm values /
.env
): ◦ Host, port, DB name(s) ◦ User, password ◦ SSL flags if required by your provider 3. Confirm the Postgres side: ◦
temporal
and
temporal_visibility
databases exist and the Temporal user has full privileges. [Create temporal DBs] ◦ Security groups / firewall /
pg_hba.conf
allow connections from the Temporal pod/container. 4. If you’re on a managed cloud DB (Azure, RDS, etc.), ensure: ◦ The DB is in a network location reachable from your cluster/host. ◦ Any required SSL configuration is present. [Azure Postgres SSL; Temporal context] If you can share your deployment type (Docker / Helm / Kustomize) and the Temporal/Postgres configuration, the logs in the sources suggest we could narrow it down further. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.