You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
airbyte-server keeps restarting on 0.60.0 – Feature flag ConfigFileClient fails with “No content to map due to end-of-input”; health endpoint unreachable
#65630
Error starting Micronaut server: Bean definition [DestinationDefinitionApiController] could not be loaded:
Error instantiating bean [DestinationServiceJooqImpl]
Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException:
No content to map due to end-of-input
at [Source: (File); line: 1, column: 1]
at io.airbyte.featureflag.ClientKt.readConfig(...)
at io.airbyte.featureflag.ConfigFileClient.(...)
Afterwards the container prints many Unsetting empty environment variable '...' lines and restarts.
What we tried
Verified inter-container networking:
docker network inspect airbyte_airbyte_internal shows expected service names and IPs.
Confirmed .env values are loaded (see above). We explicitly set:
FEATURE_FLAG_CLIENT=database to avoid file-based flags. However logs still show ConfigFileClient is being initialized and failing on an empty/absent config.
Expectation
airbyte-server starts successfully on 0.60.0.
With FEATURE_FLAG_CLIENT=database, the server shouldn’t instantiate ConfigFileClient or require a flags file.
/api/v1/health at port 8001 should return 200.
Actual
airbyte-server crashes during startup with feature-flag client initialization (“No content to map…”), then restarts; health endpoint never becomes reachable.
Questions for the Airbyte team
In v0.60.0, what is the correct env var to force database-backed feature flags? Is FEATURE_FLAG_CLIENT=database still valid, or did the name/values change?
Why is ConfigFileClient being chosen despite FEATURE_FLAG_CLIENT=database? Is there a precedence/order (e.g., if a default flags path exists it overrides)?
Is there a way to completely disable feature flags at startup (a “noop” mode) to bypass ConfigFileClient?
Do we need to set an additional var like a flags file path (FEATURE_FLAG_CONFIG_PATH) explicitly to avoid this error, or should the database client require no file at all?
Are the “Unsetting empty environment variable …” messages expected, or could blank variables in our Compose be causing early initialization side-effects?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Deploying Airbyte via Docker Compose on Windows (Docker Desktop).
Compose version: 2.29.7 (from network labels).
Services are up on bridge network airbyte_airbyte_internal; e.g. airbyte-server at 172.21.0.6, airbyte-api-server at 172.21.0.9.
.env highlights: VERSION=0.60.0, AIRBYTE_SERVER_HOST=airbyte-server:8001, AIRBYTE_API_HOST=airbyte-api-server:8006, FEATURE_FLAG_CLIENT=database, WEBAPP_URL=http://localhost:8000/.
Problem
airbyte-server container continuously restarts.
Health checks to the server fail from other containers and by IP:
curl http://airbyte-server:8001/api/v1/health → DNS/connection errors while the container is restarting.
curl http://172.21.0.6:8001/api/v1/health → connection refused / couldn’t connect.
As a result, airbyte-api-server cannot reach airbyte-server.
Key Logs (from docker compose logs --tail=200 server)
Afterwards the container prints many Unsetting empty environment variable '...' lines and restarts.
What we tried
Verified inter-container networking:
docker network inspect airbyte_airbyte_internal shows expected service names and IPs.
Health checks from inside containers:
From airbyte-api-server: curl http://airbyte-server:8001/api/v1/health → fails while server restarts.
Confirmed .env values are loaded (see above). We explicitly set:
FEATURE_FLAG_CLIENT=database to avoid file-based flags. However logs still show ConfigFileClient is being initialized and failing on an empty/absent config.
Expectation
airbyte-server starts successfully on 0.60.0.
With FEATURE_FLAG_CLIENT=database, the server shouldn’t instantiate ConfigFileClient or require a flags file.
/api/v1/health at port 8001 should return 200.
Actual
airbyte-server crashes during startup with feature-flag client initialization (“No content to map…”), then restarts; health endpoint never becomes reachable.
Questions for the Airbyte team
In v0.60.0, what is the correct env var to force database-backed feature flags? Is FEATURE_FLAG_CLIENT=database still valid, or did the name/values change?
Why is ConfigFileClient being chosen despite FEATURE_FLAG_CLIENT=database? Is there a precedence/order (e.g., if a default flags path exists it overrides)?
Is there a way to completely disable feature flags at startup (a “noop” mode) to bypass ConfigFileClient?
Do we need to set an additional var like a flags file path (FEATURE_FLAG_CONFIG_PATH) explicitly to avoid this error, or should the database client require no file at all?
Are the “Unsetting empty environment variable …” messages expected, or could blank variables in our Compose be causing early initialization side-effects?
Attachments
docker-compose.yaml
.env (with secrets redacted)
Repro Steps (minimal)
docker compose up -d
Observe airbyte-server restarting (docker compose logs --tail=200 server).
From another container: docker compose exec airbyte-api-server sh -lc "curl -sS -o /dev/null -w '%{http_code}\n' http://airbyte-server:8001/api/v1/health" → fails.
Check network: docker network inspect airbyte_airbyte_internal shows airbyte-server at 172.21.0.6.
Direct IP curl: curl http://172.21.0.6:8001/api/v1/health → can’t connect while server restarts.
.env
docker-compose.yaml
Beta Was this translation helpful? Give feedback.
All reactions