Hey all 👋 — hoping someone's hit this before. Self-hosted OSS, and I'm fully stuck. Context: this broke right after doing two things together: EKS

1.34 → 1.35

upgrade, and Airbyte Helm chart

0.551.0 → 1.9.2

(big jump, I know 😅). Since then, syncs never actually run. Symptom: jobs sit at "Starting..." forever. No replication pod is ever created — watched

kubectl get pods -n airbyte -w

live while triggering a sync, nothing appears, across multiple attempts. What I've ruled out so far: • RBAC —

airbyte-admin

SA can create pods (

kubectl auth can-i create pods --as=system:serviceaccount:airbyte:airbyte-admin

→

yes

) • DNS/networking between internal services — all fine •

kubectl get events -n airbyte

— zero `FailedCreate`/`Forbidden`/rejections, ever •

workload-launcher

— pod's healthy, only logging routine pod-sweeper cycles, nothing about the actual job •

workload-api-server

— healthy, responds fine to other calls The actual weird part: using

tctl workflow show -w replication_<jobid>

, the

StartCommand

activity completes successfully and returns a workload ID. But hitting that exact ID directly against workload-api-server:

GET /api/v1/workload/replication_<jobid>_...
→ {"message":"Could not find workload with id: ..."}

So the worker's activity thinks it created the workload and gets an ID back — but the server has zero record of it. No errors anywhere in worker/workload-launcher/workload-api-server logs about this specific job — total silence. Also noticed the chart's default images for `container-orchestrator`/`workload-init-container`/`connector-sidecar`/`async-profiler` are pinned to an alpha build (

2.0.2-alpha-c905e75

) rather than a stable tag — not sure if related, but seemed worth mentioning. Has anyone seen `StartCommand`/`createWorkload` report success while the workload record never actually persists server-side? Any pointer on where that write might be dying between worker → workload-api-server would save my week 🙏

I doubt that some has hit this before :) looks too specific to your scenario. EKS upgrade might be not a problem. The chart is another story. Basic steps to check logs of all components after restart to make sure nothing obvious pending on database side

Update — found it: a dataplane group mismatch, not the EKS/chart upgrade itself. Bootloader created a new dataplane group on upgrade, but pending workloads stayed routed to the old one, so

workload-launcher

was polling a group nobody was writing to. Fixed by pointing

dataplane.dataplane_group_id

at the right group and restarting the launcher. Known issue, GH #74275, if anyone else hits it. Thanks for the steer 🙏