erro in on premisse airbyte: This happened with Workload failed, source: workload-monitor-claim

The error "Workload failed, source: workload-monitor-claim" in an on-premise Airbyte deployment is related to the Workload Monitor — a background process that fails workloads that miss their deadlines or cannot be claimed. Common Causes Based on the knowledge sources, this type of workload claim failure can stem from several root causes: 1. Dataplane Group Mismatch (especially after upgrades) After upgrading to Airbyte 2.0.x, jobs may be pushed to one dataplane group while the workload launcher is listening to a different one. You can check this by querying the Airbyte database:

SELECT * FROM public.dataplane_group;
SELECT id, organization_id, dataplane_group_id FROM public.workspace;

If there are two dataplane groups and the workspace is pointing to the wrong one, update the

dataplane_group_id

in the workspace table to match the active dataplane group. [dataplane group mismatch] 2. Workloads Stuck in "Launched" Status (Deadlock) A known issue can cause workloads to remain in

launched

status indefinitely. The launcher requires a successful claim to run the

CHECK_STATUS

stage, but claims fail if the workload is already in

launched

state — creating a deadlock where status is never updated. [stuck workloads] 3. Authentication Misconfiguration (WORKLOAD_API_BEARER_TOKEN) If the

WORKLOAD_API_BEARER_TOKEN

and

WORKLOAD_API_AUTH_HEADER

are not aligned between the Worker and Workload API Server pods, API calls will be rejected with 401 errors, preventing workloads from being claimed. The fix is to set the same token on all relevant deployments:

TOKEN=$(openssl rand -hex 24)
kubectl -n airbyte-abctl set env deployment/airbyte-abctl-workload-api-server WORKLOAD_API_AUTH_HEADER=Authorization WORKLOAD_API_BEARER_TOKEN=$TOKEN
kubectl -n airbyte-abctl set env deployment/airbyte-abctl-worker WORKLOAD_API_AUTH_HEADER=Authorization WORKLOAD_API_BEARER_TOKEN=$TOKEN

[auth token fix] Debugging Steps Check the workload-launcher logs for more details:

kubectl logs -l app.kubernetes.io/name=workload-launcher --namespace <airbyte-namespace> --tail=100

Also check Kubernetes events for pod creation failures:

kubectl get events --namespace <airbyte-namespace> --field-selector reason=FailedCreate

[debugging steps] If none of these apply to your situation, please share more details from your workload-launcher and workload-api-server logs for further diagnosis. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.