Workload failed, source: workload-launcher

There are several known causes for workload failures originating from the

workload-launcher

in Airbyte. Here are the most common ones based on reported issues: 1. Dataplane Group Mismatch (After Upgrade from 1.7.x to 2.0.x) Symptom: All syncs stuck in "Queued" with the error: >

Airbyte could not start the process within time limit. The workload was never claimed.

Root Cause: After upgrading, the bootloader creates a new

dataplane_group

UUID, but existing workloads are still routed to the old

AUTO

group. The workload-launcher only polls for workloads matching its registered group, so workloads are never claimed. [Dataplane Group Mismatch] Workaround: Update all dataplanes to point to the existing

AUTO

group via SQL, then restart the launcher:

UPDATE dataplane
SET dataplane_group_id = '<old-AUTO-group-id>'
WHERE dataplane_group_id = '<new-group-id>';

kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl

[Dataplane Group Mismatch] 2. KubeClientException: Failed to Create Pod Symptom: The launcher fails to create a replication or check pod (e.g.,

replication-job-185-attempt-0

or

rce-postgres-check

). Known sub-causes: • Duplicate

imagePullSecrets

in the pod spec causes a Kubernetes PATCH failure with a 500 error. [Helm workload-launcher error] • Wrong or missing ServiceAccount — if a non-default service account is used, the launcher may still try to use

airbyte-admin

, causing a forbidden error. [Service account issue] • Node scheduling issues (e.g., ARM64 nodes via Karpenter) where workload pods are scheduled on incompatible architecture nodes. [Failed to create pod] • Init container failure (

ContainerStatusUnknown

or

Error

) during pod startup. [Replication pod failure] 3. Storage Connection Loss (Zombie Launcher) Symptom: Syncs never start; the launcher pod appears healthy but cannot process work. Root Cause: If the

workload-launcher

loses its connection to the configured storage (e.g., Azure Blob, S3, MinIO), it becomes a zombie — passing liveness probes but unable to function. The fix is to delete and recreate the pod. [False positive liveness probes] General Troubleshooting Steps 1. Check workload-launcher logs:kubectl logs -l app.kubernetes.io/name=workload-launcher --namespace airbyte-namespace --tail=100 2. Check Kubernetes events for pod creation failures:kubectl get events --namespace airbyte-namespace --field-selector reason=FailedCreate 3. Describe the failed pod for scheduling or image-pull issues:kubectl describe pod pod-name -n airbyte-namespace If you can share the specific error message or logs from your

workload-launcher

, I can help narrow down the exact cause. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.