Hello, TLDR; I have fresh deployment of Airbyte2.0...
# replication-troubleshooting
k
Hello, TLDR; I have fresh deployment of Airbyte2.0.18 on Azure AKS cluster. It is up and running but when I try to create source connection it is throwing 502 error. Does anyone know how to resolve it ? looking for help with Airbyte 2.0.1 on Kubernetes (Helm chart 2.0.18). Saving/testing any source (e.g. MySQL) fails with: UI: Failed to save … errors.http.badGateway / Airbyte is temporarily unavailable (HTTP 502) No connector check pods are created Environment Helm chart: 2.0.18 (Artifactory mirror of airbyte chart) Platform: 2.0.1 (airbyte/workload-launcher:2.0.1) Edition: community Deployment: AKS, single namespace (hybrid CP+DP) DB: external Azure PostgreSQL Storage: Azure Blob (STORAGE_TYPE=azure, connection string via K8s secret / ExternalSecrets) Auth: global.auth.enabled: true Ingress → airbyte-server on :8001 What works UI loads, server/temporal/worker/workload-api-server pods healthy (after fixing temporal.database.engine → postgres12) ExternalSecrets synced; AZURE_STORAGE_CONNECTION_STRING set on launcher Blob containers exist (airbyte-v2-state, airbyte-v2-workloadoutput, airbyte-v2-logs) Network from launcher pod to storage: curl to *.blob.core.windows.net connects (TLS OK) Dataplane routing OK: workspace + workload dataplane_group_id match launcher ApiQueuePoller UUID; dataplane enabled=true Workload-launcher polls queue successfully: POST /api/v1/workload/queue/poll → 200 What fails On source test, workload row stays pending → later failure with termination_reason: "The workload was never claimed" and dataplane_id NULL Launcher log shows dequeue + APPLY Stage: BUILD for *_check workload, then no LAUNCH, no check pod After BUILD starts, Azure SDK logs Netty client + version mismatch warning: azure-netty 4.1.118.Final vs classpath Netty 4.2.4.Final HTTP pool created for stairbytedveu1.blob.core.windows.net:443, then silence (no LAUNCH, no exception in grep window) WLAS logs during test show worker GET /api/v1/workload/{id}_check (200) but no launcher claim traffic in that window (launcher seems stuck in BUILD before claim completes) Config notes workloadLauncher.hpa.enabled: false, replicaCount: 1 WORKLOAD_LAUNCHER_ENABLED_NAMESPACES set to same namespace as JOB_KUBE_NAMESPACE WORKLOAD_API_AUTH_HEADER + WORKLOAD_API_BEARER_TOKEN (jwt secret) on worker + workloadApiServer + workloadLauncher Tried JAVA_TOOL_OPTIONS=-Dio.netty.transport.noNative=true on launcher — BUILD still hangs Questions Is BUILD hanging on Azure Blob with Netty version mismatch a known issue on 2.0.1 / chart 2.0.18? Recommended fix (image/chart version, JVM flags)? Should WORKLOAD_API_BEARER_TOKEN on workload-launcher be set manually when auth.enabled=true, or does chart wire internal JWT only? Any required Helm values for Azure storage + workload-launcher BUILD we might be missing? Related issues we’ve seen: #68115, #70451, #74275 — our case looks like poll works but BUILD never reaches LAUNCH. Happy to share redacted launcher logs (BUILD → blob pool) and workload table rows if helpful. Thanks!