Describe the bug
The Host Client health and registration endpoints can incorrectly report defradb_connected: false and status: "not ready" even when DefraDB is fully operational and syncing normally.
The issue occurs when DEFRA_URL is configured as 0.0.0.0:9181, which is a valid listen address for DefraDB. The health check appears to reuse this configured address as the dial target when checking DefraDB connectivity.
In pkg/server/health.go, checkDefraDB only returns true when the URL contains localhost or 127.0.0.1. Otherwise, it attempts to call: <DEFRA_URL>/api/v0/graphql
With the documented Docker setup using DEFRA_URL=0.0.0.0:9181, this connectivity check fails, resulting in a false defradb_connected: false status.
This has become user-facing because the Explorer frontend now uses defradb_connected === true to determine whether a host is Online. As a result, healthy and fully synced hosts can incorrectly appear Offline.
To Reproduce
- Run the Host Client with DefraDB in the documented Docker setup.
- Configure DEFRA_URL=0.0.0.0:9181.
- Ensure DefraDB is running and serving GraphQL requests normally.
- Check the Host Client /health or /registration endpoint.
- Observe that defradb_connected is false and the status is "not ready".
- Check DefraDB directly and confirm that GraphQL is working and the node is syncing normally.
- Observe that the Explorer may show the host as Offline because it relies on defradb_connected.
Expected behavior
The health check should correctly detect DefraDB as connected when DefraDB is running and reachable, regardless of whether DEFRA_URL is configured with a listen address such as 0.0.0.0:9181.
The configured listen address and the address used by the Host Client to connect to DefraDB should be handled separately if necessary.
One possible fix is to use 127.0.0.1:9181 as the dial target when the configured DefraDB address is 0.0.0.0:9181.
Screenshots
Not provided. Health endpoint output and Explorer status can be added if needed.
Additional context
Relevant code: pkg/server/health.go (checkDefraDB).
The client confirmed that DefraDB GraphQL and syncing work correctly despite the failed health check.
Workaround: run the container with --network host and set DEFRA_URL=127.0.0.1:9181. This immediately makes the host appear Online.
The issue may affect hosts using the documented Docker configuration with DEFRA_URL=0.0.0.0:9181.
Describe the bug
The Host Client health and registration endpoints can incorrectly report
defradb_connected: falseandstatus: "not ready"even when DefraDB is fully operational and syncing normally.The issue occurs when
DEFRA_URLis configured as0.0.0.0:9181, which is a valid listen address for DefraDB. The health check appears to reuse this configured address as the dial target when checking DefraDB connectivity.In
pkg/server/health.go, checkDefraDB only returns true when the URL contains localhost or 127.0.0.1. Otherwise, it attempts to call:<DEFRA_URL>/api/v0/graphqlWith the documented Docker setup using
DEFRA_URL=0.0.0.0:9181, this connectivity check fails, resulting in a falsedefradb_connected: falsestatus.This has become user-facing because the Explorer frontend now uses
defradb_connected === trueto determine whether a host is Online. As a result, healthy and fully synced hosts can incorrectly appear Offline.To Reproduce
Expected behavior
The health check should correctly detect DefraDB as connected when DefraDB is running and reachable, regardless of whether DEFRA_URL is configured with a listen address such as
0.0.0.0:9181.The configured listen address and the address used by the Host Client to connect to DefraDB should be handled separately if necessary.
One possible fix is to use
127.0.0.1:9181as the dial target when the configured DefraDB address is0.0.0.0:9181.Screenshots
Not provided. Health endpoint output and Explorer status can be added if needed.
Additional context
Relevant code: pkg/server/health.go (checkDefraDB).
The client confirmed that DefraDB GraphQL and syncing work correctly despite the failed health check.
Workaround: run the container with --network host and set
DEFRA_URL=127.0.0.1:9181. This immediately makes the host appear Online.The issue may affect hosts using the documented Docker configuration with DEFRA_URL=0.0.0.0:9181.