@kapa.ai: i.m.r.Micronaut(handleStartupException):362 - Error starting Micronaut server: Failed to initialize data-plane

The error

Error starting Micronaut server: Failed to initialize data-plane

has been observed in several Airbyte deployment scenarios. Here are the known causes and context from the knowledge sources: Known Causes 1. Server Not Reachable (Connection Refused) The workload-launcher fails to initialize the data-plane because it cannot connect to the Airbyte server:

java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc/10.43.100.0:8001
...
java.lang.RuntimeException: Failed to initialize data-plane
    at io.airbyte.workload.launcher.authn.DataplaneIdentityService.initialize(DataplaneIdentityService.kt:58)

This typically means the airbyte-server pod itself is failing to start, causing the workload-launcher to be unable to reach it. [Multiple issues 2.0.0 chart] 2. Authentication / Token Failure (HTTP 500 / 401) The data-plane initialization can also fail due to authentication issues:

ERROR i.a.a.c.a.AccessTokenInterceptor(intercept) - Failed to obtain or add access token
java.lang.Exception: Token request failed with HTTP code 500
Caused by: ClientException: Client error : 401 Unauthorized

This has been linked to issues with the

airbyte-auth-secrets

Kubernetes secret not being properly created or managed. [Dataplane Group Mismatch; v1.6.0 deploy issue] 3. Underlying Server Bean Initialization Failure If the Airbyte server itself crashes during startup (e.g., due to misconfigured storage, bean instantiation errors, or Temporal Cloud incompatibilities), the workload-launcher will subsequently fail to initialize the data-plane because the server is unavailable. [Multiple issues 2.0.0 chart] Recommended Troubleshooting Steps 1. Check the airbyte-server pod logs first — the root cause is often there, not in the workload-launcher itself. 2. Verify the

airbyte-auth-secrets

Kubernetes secret exists and is correctly populated. Pre-creating it externally can cause issues if it's not being updated properly. [v1.6.0 deploy issue] 3. Check storage configuration — misconfigured storage (e.g., wrong case for

global.storage.type

, missing GCS credentials) can prevent the server from starting. [Storage type case issue] 4. If upgrading from 1.7.x to 2.0.x, stale Temporal workflows can cause syncs to be stuck and related initialization failures. [Dataplane Group Mismatch] Could you share more context about your deployment (Helm chart version, upgrade vs. fresh install, storage type) and the full logs from the airbyte-server pod? That would help narrow down the root cause. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.