Luis Gustavo Macedo Lousada
12/08/2025, 8:19 PM2025-12-08 19:34:30,213 [Workflow Executor taskQueue="ui_commands", namespace="default": 1] WARN i.t.i.r.ReplayWorkflowTaskHandler(failureToWFTResult):302 - Workflow task processing failure. startedEventId=3, WorkflowId=check_b83dd098-8e2d-4741-84f5-0bd4390fd5f8, RunId=019aff75-4b49-7898-aff4-ecf3f6c52233. If seen continuously the workflow might be stuck.
io.temporal.internal.statemachines.InternalWorkflowTaskException: Failure handling event 3 of type 'EVENT_TYPE_WORKFLOW_TASK_STARTED' during execution. {WorkflowTaskStartedEventId=3, CurrentStartedEventId=3}
Caused by: io.temporal.internal.sync.PotentialDeadlockException: [TMPRL1101] Potential deadlock detected. Workflow thread "workflow-method-check_b83dd098-8e2d-4741-84f5-0bd4390fd5f8-019aff75-4b49-7898-aff4-ecf3f6c52233" didn't yield control for over a second. {detectionTimestamp=1765222469954, threadDumpTimestamp=1765222469957}
workflow-method-check_b83dd098-8e2d-4741-84f5-0bd4390fd5f8-019aff75-4b49-7898-aff4-ecf3f6c52233
at kotlin.reflect.jvm.internal.impl.types.KotlinTypeFactory.flexibleType(KotlinTypeFactory.kt:188)kapa.ai
12/08/2025, 8:20 PMJarFile). The key parts are: - Workflow task processing failure … If seen continuously the workflow might be stuck. - io.temporal.internal.sync.PotentialDeadlockException: [TMPRL1101] Potential deadlock detected. Workflow thread "workflow-method-check_…" didn't yield control for over a second. [[Temporal deadlock on EKS](https://github.com/airbytehq/airbyte/issues/59730)] In Airbyte, this usually shows up when running a check connection / test destination workflow and the underlying worker or pod is slow or blocked. In a related case the root cause was the worker hanging while waiting for a Kubernetes pod, and the Temporal workflow then timing out / deadlocking from Temporal’s point of view.[[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] Given what’s in the sources, here’s how you can debug and work around it: 1. Check worker pod logs around the same timestamp Look for: - WorkerException: Error while getting checking connection - Timeouts like Timed out waiting for [300000] milliseconds for [Pod] with name:[destination-...-check-...] These indicate the worker is blocked waiting on a K8s pod, which can trigger the Temporal deadlock warning.[[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] 2. Verify the check pod is actually being created and starting - In your cluster, look for pods named like destination-<connector>-check-.... - If they stay in Pending or never appear, you likely have: - Insufficient resources / scheduling issues. - Bad namespace or RBAC so the worker can’t create/watch pods. Temporal just surfaces the symptom; the real issue is the pod not progressing.[[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] 3. Confirm worker startup health In a similar issue, the worker had just started, then immediately hit the Temporal error; checking that the airbyte-worker pod is fully up and healthy (no restarts / OOM / image pull issues) is important.[[Temporal context deadline](https://github.com/airbytehq/airbyte/issues/59730)] 4. Retry the check and watch for “continuous” failures Temporal logs say “If seen continuously the workflow might be stuck” – an occasional one-off can be transient, but repeated failures for every check mean the underlying blocking condition (e.g. pod never starting) is persistent.[[Temporal context deadline](https://github.com/airbytehq/airbyte/issues/59730)] 5. If you’re on Kubernetes: - Confirm: - The worker’s service account has permission to create/watch pods in the Airbyte namespace. - There are enough CPU/memory for check pods. - If you see Kubernetes client timeouts in logs (as in the forum post), increase or investigate the pod startup timeout.[[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] The knowledge sources don’t show a specific fix for the Kotlin stack frame you’re seeing; they just show that Temporal’s PotentialDeadlockException is a symptom when the workflow thread is blocked in user code or in waiting for K8s. I’d focus your debugging on: - airbyte-worker logs (full stack trace around the error). - Status/events of the destination check pod in the cluster. - Any timeouts or permission errors in those logs. If you can share the full worker log for that check attempt (including lines after the Temporal warning), you can often pinpoint whether it’s a K8s timeout, connector image startup issue, or something else.Luis Gustavo Macedo Lousada
12/08/2025, 9:52 PMkapa.ai
12/08/2025, 9:53 PMkapa.ai
12/08/2025, 9:54 PMReplayWorkflowTaskHandler … Workflow task processing failure … If seen continuously the workflow might be stuck. - Caused by: java.lang.RuntimeException: WorkflowTask: failure executing SCHEDULED->WORKFLOW_TASK_STARTED… - Caused by: io.temporal.internal.sync.PotentialDeadlockException: [TMPRL1101] Potential deadlock detected. Workflow thread "workflow-method-check_…" didn't yield control for over a second. In previous Airbyte cases: - The same Temporal error happened for check connection / test destination workflows. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] - The actual root cause was the worker getting “stuck” doing some blocking work (often around connector startup / Kubernetes pods), and Temporal just reports it as a potential deadlock. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] Given what is documented, here’s how you can debug with Airbyte-specific checks: 1. Look for the underlying worker error in the same time window In similar incidents, after the Temporal stack you see a more “Airbyte-ish” exception such as: - io.airbyte.workers.exception.WorkerException: Error while getting checking connection. - Caused by: io.fabric8.kubernetes.client.KubernetesClientTimeoutException: Timed out waiting for [300000] milliseconds for [Pod] with name:[destination-...-check-...] in namespace [default]. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] Scroll further up/down in airbyte-worker logs around 2025-12-08 19:34:30 to see if there is: - A WorkerException - A Kubernetes timeout - A connector / image error That error is usually the real cause. 2. If you run on Kubernetes, validate check pods The check workflow starts a short‑lived check pod such as destination-<name>-check-<id>-<rand>. In the documented cases, Temporal errors appeared because these pods never became Running within 300s. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] Check: bash kubectl get pods -n <airbyte-namespace> | grep check_b83dd098 kubectl get pods -n <airbyte-namespace> | grep destination- # or your destination type For any check pod corresponding to your test: - If it’s `Pending`: likely scheduling/resources or permissions. - If it’s Init:0/1 forever: investigate events (kubectl describe pod ...) for image pull errors, volume errors, etc. - If no pod appears: verify that the worker service account can create pods and that the worker is healthy. In previous reports, increasing resources / fixing scheduling so these pods can start resolved the “hanging” checks. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] 3. Check Temporal / worker resource constraints Another user saw errors like DEADLINE_EXCEEDED … tied to lack of memory for Temporal, which led to stuck workflows. They were advised to increase node/Temporal memory. [[Salesforce connections stuck](https://discuss.airbyte.io/t/1612)] Confirm: - airbyte-worker and airbyte-temporal pods are not OOM‑killed or throttled. - Resource limits are sufficient; if Temporal memory is very low (e.g. 512Mi as in the example), consider raising it. [[Salesforce connections stuck](https://discuss.airbyte.io/t/1612)] 4. Look for repeated “If seen continuously” messages Temporal logs say: > If seen continuously the workflow might be stuck. If this happens on every test, your workflow is consistently blocked (e.g., every check pod fails to start). If it’s just once or twice, it may be transient. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] --- What the docs don’t show: - There’s no Airbyte‑specific fix for the exact Kotlin stack you posted (reflection / type resolution in Kotlin). - There is no configuration flag described in the sources to “turn off” Temporal’s deadlock detection. So, based on the available information, the best concrete path is: 1. Inspect full airbyte-worker logs for a WorkerException or Kubernetes / connector error tied to this check. 2. On Kubernetes, inspect the corresponding destination-...-check pod status and events. 3. Ensure Temporal / worker have enough resources and are not restarting. If you can share the lines immediately before/after this stack trace that mention DefaultCheckConnectionWorker, AirbyteIntegrationLauncher, or KubeProcessFactory / KubePodProcess, that will likely reveal the underlying failure cause (pod timeout, image problem, etc.), as seen in the linked cases.Luis Gustavo Macedo Lousada
12/08/2025, 9:59 PMkapa.ai
12/08/2025, 9:59 PMkapa.ai
12/08/2025, 9:59 PMkapa.ai
12/08/2025, 10:00 PMPotentialDeadlockException in the check_... workflow (like your stack trace). - No destination-...-check-... pod ever appears. - The root cause is in the airbyte-worker itself (it never successfully issues the K8s pod create, or is blocked before doing so). From the available sources, here’s how to debug when no check pod is created: 1. Confirm worker can create pods / has K8s access Other failures show that if the worker cannot talk to the cluster or create pods, the check fails inside the worker with a KubeClientException / KubernetesClientException, before any pod exists.[[Kube client failure](https://github.com/airbytehq/airbyte/issues/52034); [Kubernetes FileNotFound](https://discuss.airbyte.io/t/1716)] Check in your airbyte-worker logs around the check time for any of: - KubeClientException: Failed to create pod ... [[Kube client failure](https://github.com/airbytehq/airbyte/issues/52034)] - KubernetesClientException or KubernetesClientTimeoutException - Errors around kube config like java.io.FileNotFoundException: /root/.kube/config (for non‑in‑cluster configs). [[Kubernetes FileNotFound](https://discuss.airbyte.io/t/1716)] If you see these, it means the worker never successfully creates the check pod. 2. Verify worker pod health and task handling In the EKS issue, the symptom was that the worker starts but then doesn’t log anything when a check is requested, and no pod is created.[[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] - Ensure the airbyte-worker pod is Running, not restarting, and has enough CPU/memory. - Look for log entries like: - Attempting to start pod = destination-...-check-... from KubeProcessFactory or KubePodClient. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] - If those lines are missing entirely for your check, the worker may not be picking up the Temporal activity. 3. Check Temporal symptoms When checks hang or pods are never ready, existing logs show Temporal warnings similar to yours followed by WorkerException: Error while getting checking connection and timeouts waiting for a pod.[[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] In your case, you only posted the Temporal deadlock trace. If no WorkerException or KubeProcessFactory logs follow, the workflow might be getting stuck before it even reaches the pod-launch step (within Airbyte’s check workflow or some library code). 4. What you can do next, practically Based on the documented patterns (and limited info): - Tail airbyte-worker logs while you click “Test”: bash kubectl logs -n <airbyte-namespace> deploy/airbyte-worker -f and look for any error near your check_b83dd098... workflow id, especially: - DefaultCheckConnectionWorker - AirbyteIntegrationLauncher.check - KubeProcessFactory.create or KubePodClient.launchCheck [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293); [Kube client failure](https://github.com/airbytehq/airbyte/issues/52034)] - If you see a Kubernetes or RBAC error there, fix that (permissions, kubeconfig, in‑cluster config). - If you don’t see any attempt to create a pod in the logs (Attempting to start pod = ...), then the check workflow is failing or blocked earlier; the sources do not provide a concrete, general fix for this situation beyond inspecting those worker logs. Because the knowledge sources stop at similar symptoms and don’t document a definitive fix for the “no check pod + Temporal deadlock” combination on recent versions, I cannot point to a specific configuration change to guarantee resolution. The next concrete step must be to identify the first Airbyte‑level error in the worker logs when you trigger the check, and then address that cause (K8s access, timeouts, or worker health) as in the linked issues.kapa.ai
12/08/2025, 10:00 PM*-check-* pod ever appears in the cluster. - The worker looks “stuck” and Temporal logs workflow errors / potential deadlock. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] From the available cases, here’s how to debug this step‑by‑step. --- ## 1. Confirm worker is attempting to start a pod In a healthy check, the airbyte-worker logs should show something like: text Attempting to start pod = destination-s3-check-192-0-qcbyl for airbyte/destination-s3:... ... Creating pod destination-s3-check-192-0-qcbyl... or similar source-...-check-.... [[Sync hangs waiting pod](https://discuss.airbyte.io/t/1687); [Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] If you do not see any Attempting to start pod = ...check... line around the time you click “Test connection”, then the workflow might be failing before it reaches the pod creation code (e.g., inside the Temporal workflow / Kotlin stack you posted). In that case: - Look in the same worker log for any WorkerException mentioning check connection. - Also check Temporal server logs for DEADLINE_EXCEEDED or similar (seen in other stuck‑workflow cases). [[Salesforce connections stuck](https://discuss.airbyte.io/t/1612)] --- ## 2. If worker logs do say “Attempting to start pod”, but no pod shows up This pattern appears in several Kubernetes deployments where Airbyte can’t successfully create the pod: - Errors like: text WorkerException: Operation: [create] for kind: [Pod] ... failed. Caused by: io.fabric8.kubernetes.client.KubernetesClientException when the worker’s Kubernetes client cannot create the pod. [[Kubernetes FileNotFound kubeconfig](https://discuss.airbyte.io/t/1716)] - Or timeouts like: text Timed out waiting for [300000] milliseconds for [Pod] with name:[destination-snowflake-check-...] in namespace [default]. Caused by: KubernetesClientTimeoutException when the pod is created but never becomes ready. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] Actions: 1. Search the airbyte-worker logs for: - Operation: [create] for kind: [Pod] - KubernetesClientException or KubernetesClientTimeoutException - Timed out waiting for [300000] milliseconds for [Pod] These messages will tell you if: - The create call fails immediately (likely RBAC / kubeconfig / namespace issue). [[Kubernetes FileNotFound kubeconfig](https://discuss.airbyte.io/t/1716)] - Or Airbyte waits and times out because the pod never becomes ready (scheduling/resources). [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] 2. If you see “Operation: [create] for kind: [Pod] … failed”: - In similar cases, the underlying cause was misconfigured Kubernetes client access (e.g. missing kubeconfig when running out‑of‑cluster, or no permissions). [[Kubernetes FileNotFound kubeconfig](https://discuss.airbyte.io/t/1716)] - Ensure that: - The airbyte-worker pod is running inside the cluster and uses in‑cluster config, or - If running out‑of‑cluster, it has a valid ~/.kube/config or configured KUBECONFIG. The linked example shows java.io.FileNotFoundException: /root/.kube/config causing pod creation failure. [[Kubernetes FileNotFound kubeconfig](https://discuss.airbyte.io/t/1716)] 3. If you see timeouts: - The pod is being created but stuck in Pending/Init. You then need to use kubectl describe pod ... to find image pull, volume, or scheduling issues, as shown in the sync‑hang examples. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293); [Sync hangs waiting pod](https://discuss.airbyte.io/t/1687)] --- ## 3. If no “Attempting to start pod” and only Temporal deadlock In your current logs, Temporal is throwing PotentialDeadlockException inside Kotlin reflection code during the check_* workflow. The knowledge sources do not document this exact Kotlin stack, but they do note that: - Temporal logs “If seen continuously the workflow might be stuck”. - In similar reports, the workflow was effectively stuck and user‑visible effect was: test/check never starts a pod, returning 502 or failing silently. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] Given that: 1. Verify if any check or sync works at all, or all checks fail (including very simple connectors like PokeAPI). In the EKS case, all checks failed and no check pods were ever created. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] 2. Check resource usage and restarts of: - airbyte-worker - airbyte-temporal (or Temporal server) In other stuck‑workflow reports, Temporal timeouts and stuck workflows were correlated with low resources or unstable Temporal deployment. [[Salesforce connections stuck](https://discuss.airbyte.io/t/1612)] 3. If everything looks healthy but the workflow code itself is deadlocking inside Kotlin reflection (as your stack suggests), the current knowledge base doesn’t provide a documented Airbyte‑side configuration fix. In that case, capturing: - Full airbyte-worker logs for one failing “test destination” attempt. - Confirmation that no Attempting to start pod line appears. - The Temporal logs you already shared. …and attaching them to an issue (or the existing Temporal‑related ones) would be the next step, since this could be a bug in the check workflow implementation or in the version you’re running. The EKS Temporal issue used this same process (sharing full logs) to move forward. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] --- ### Minimal checklist for you now 1. Run a test on any destination. 2. Immediately after: - kubectl logs <airbyte-worker-pod> -n <ns> Search for: - Attempting to start pod = - Operation: [create] for kind: [Pod] - KubernetesClientException, KubernetesClientTimeoutException - kubectl get pods -n <ns> | grep check- Confirm no check pod appears. 3. Based on what you find: - Create fails → fix Kubernetes client access / RBAC / kubeconfig. [[Kubernetes FileNotFound kubeconfig](https://discuss.airbyte.io/t/1716)] - Times out → debug pod Pending/Init state. [[Temporal scheduler hang](https://discuss.airbyte.io/t/1293)] - No pod attempt logged, only Temporal deadlock → likely workflow bug; gather logs as above and escalate (the sources don’t document a config workaround). If you can paste the lines from airbyte-worker that mention DefaultCheckConnectionWorker, AirbyteIntegrationLauncher, or KubeProcessFactory around your test attempt, I can help interpret them against the known patterns.