<@U04S8PLJWMT> the airbyte-worker throw this error...
# ask-ai
l
@kapa.ai the airbyte-worker throw this error when try test a destination, how can fix or debug this bro???
Copy code
2025-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}
Copy code
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)
k
Your error is the same Temporal “potential deadlock” pattern that appears in existing Airbyte reports, just with a different stack frame (Kotlin lib instead of
JarFile
). 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.
l
@kapa.ai This is full stack trace 2025-12-08 193430,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} at io.temporal.internal.statemachines.WorkflowStateMachines.createEventProcessingException(WorkflowStateMachines.java:436) at io.temporal.internal.statemachines.WorkflowStateMachines.handleEventsBatch(WorkflowStateMachines.java:338) at io.temporal.internal.statemachines.WorkflowStateMachines.handleEvent(WorkflowStateMachines.java:297) at io.temporal.internal.replay.ReplayWorkflowRunTaskHandler.applyServerHistory(ReplayWorkflowRunTaskHandler.java:260) at io.temporal.internal.replay.ReplayWorkflowRunTaskHandler.handleWorkflowTaskImpl(ReplayWorkflowRunTaskHandler.java:242) at io.temporal.internal.replay.ReplayWorkflowRunTaskHandler.handleWorkflowTask(ReplayWorkflowRunTaskHandler.java:165) at io.temporal.internal.replay.ReplayWorkflowTaskHandler.handleWorkflowTaskWithQuery(ReplayWorkflowTaskHandler.java:135) at io.temporal.internal.replay.ReplayWorkflowTaskHandler.handleWorkflowTask(ReplayWorkflowTaskHandler.java:100) at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.handleTask(WorkflowWorker.java:475) at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.handle(WorkflowWorker.java:366) at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.handle(WorkflowWorker.java:306) at io.temporal.internal.worker.PollTaskExecutor.lambda$process$1(PollTaskExecutor.java:96) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583) Caused by: java.lang.RuntimeException: WorkflowTask: failure executing SCHEDULED->WORKFLOW_TASK_STARTED, transition history is [CREATED->WORKFLOW_TASK_SCHEDULED] at io.temporal.internal.statemachines.StateMachine.executeTransition(StateMachine.java:163) at io.temporal.internal.statemachines.StateMachine.handleHistoryEvent(StateMachine.java:103) at io.temporal.internal.statemachines.EntityStateMachineBase.handleEvent(EntityStateMachineBase.java:84) at io.temporal.internal.statemachines.EntityStateMachineInitialCommand.handleEvent(EntityStateMachineInitialCommand.java:70) at io.temporal.internal.statemachines.WorkflowStateMachines.handleSingleEvent(WorkflowStateMachines.java:487) at io.temporal.internal.statemachines.WorkflowStateMachines.handleEventsBatch(WorkflowStateMachines.java:336) ... 13 common frames omitted 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) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.transformJavaClassifierType(JavaTypeResolver.kt:117) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.transformJavaType(JavaTypeResolver.kt:58) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.transformToTypeProjection(JavaTypeResolver.kt:305) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.computeArguments(JavaTypeResolver.kt:275) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.computeSimpleJavaClassifierType(JavaTypeResolver.kt:135) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.transformJavaClassifierType(JavaTypeResolver.kt:104) at kotlin.reflect.jvm.internal.impl.load.java.lazy.types.JavaTypeResolver.transformJavaType(JavaTypeResolver.kt:58) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassDescriptor$LazyJavaClassTypeConstructor.computeSupertypes(LazyJavaClassDescriptor.kt:226) at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor$supertypes$1.invoke(AbstractTypeConstructor.kt:78) at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor$supertypes$1.invoke(AbstractTypeConstructor.kt:77) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValueWithPostCompute.invoke(LockBasedStorageManager.java:481) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValueWithPostCompute.invoke(LockBasedStorageManager.java:512) at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor.getSupertypes(AbstractTypeConstructor.kt:27) at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor.getSupertypes(AbstractTypeConstructor.kt:26) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.computeFunctionNames(LazyJavaClassMemberScope.kt:74) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.computeFunctionNames(LazyJavaClassMemberScope.kt:63) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope$functionNamesLazy$2.invoke(LazyJavaScope.kt:259) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope$functionNamesLazy$2.invoke(LazyJavaScope.kt:259) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527) at kotlin.reflect.jvm.internal.impl.storage.StorageKt.getValue(storage.kt:42) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.getFunctionNamesLazy(LazyJavaScope.kt:259) at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.getFunctionNames(LazyJavaScope.kt:263) at kotlin.reflect.jvm.internal.impl.builtins.jvm.JvmBuiltInsCustomizer.getFunctionsNames(JvmBuiltInsCustomizer.kt:184) at kotlin.reflect.jvm.internal.impl.builtins.jvm.JvmBuiltInsCustomizer.getFunctionsNames(JvmBuiltInsCustomizer.kt:50) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassMemberScope.getNonDeclaredFunctionNames(DeserializedClassDescriptor.kt:354) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation$functionNames$2.invoke(DeserializedMemberScope.kt:258) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation$functionNames$2.invoke(DeserializedMemberScope.kt:257) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527) at kotlin.reflect.jvm.internal.impl.storage.StorageKt.getValue(storage.kt:42) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation.getFunctionNames(DeserializedMemberScope.kt:257) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope.getFunctionNames(DeserializedMemberScope.kt:59) at kotlin.reflect.jvm.internal.impl.resolve.scopes.SubstitutingScope.getFunctionNames(SubstitutingScope.kt:89) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassMemberScope.getNonDeclaredFunctionNames(DeserializedClassDescriptor.kt:353) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation$functionNames$2.invoke(DeserializedMemberScope.kt:258) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation$functionNames$2.invoke(DeserializedMemberScope.kt:257) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527) at kotlin.reflect.jvm.internal.impl.storage.StorageKt.getValue(storage.kt:42) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation.getFunctionNames(DeserializedMemberScope.kt:257) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$OptimizedImplementation.addFunctionsAndPropertiesTo(DeserializedMemberScope.kt:357) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope.computeDescriptors(DeserializedMemberScope.kt:115) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassMemberScope$allDescriptors$1.invoke(DeserializedClassDescriptor.kt:277) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassMemberScope$allDescriptors$1.invoke(DeserializedClassDescriptor.kt:276) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408) at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527) at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassMemberScope.getContributedDescriptors(DeserializedClassDescriptor.kt:287) at kotlin.reflect.jvm.internal.impl.resolve.scopes.InnerClassesScopeWrapper.getContributedDescriptors(InnerClassesScopeWrapper.kt:35) at kotlin.reflect.jvm.internal.impl.resolve.scopes.InnerClassesScopeWrapper.getContributedDescriptors(InnerClassesScopeWrapper.kt:27) at kotlin.reflect.jvm.internal.impl.resolve.scopes.ResolutionScope$DefaultImpls.getContributedDescriptors$default(ResolutionScope.kt:50) at kotlin.reflect.jvm.internal.KClassImpl$Data$nestedClasses$2.invoke(KClassImpl.kt:111) at kotlin.reflect.jvm.internal.KClassImpl$Data$nestedClasses$2.invoke(KClassImpl.kt:110) at kotlin.reflect.jvm.internal.ReflectProperties$LazySoftVal.invoke(ReflectProperties.java:70) at kotlin.reflect.jvm.internal.ReflectProperties$Val.getValue(ReflectProperties.java:32) at kotlin.reflect.jvm.internal.KClassImpl$Data.getNestedClasses(KClassImpl.kt:110) ... more
k
A message from kapa.ai
This stack trace matches the Temporal “potential deadlock” pattern already reported for Airbyte checks, just with a different Java/Kotlin stack. [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] Key points from your log: -
ReplayWorkflowTaskHandler … 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:
Copy code
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.
l
@kapa.ai check pods not is created
k
A message from kapa.ai
A message from kapa.ai
If the check pod is not created at all, you’re in the same situation described in the Temporal / EKS issue and some K8s threads: > “the check pod never starts, and the Kubernetes cluster does not show any logs indicating that the pod was requested to be created. I also noticed that the airbyte-worker seems to be stuck after launching…” [[Temporal deadline on EKS](https://github.com/airbytehq/airbyte/issues/59730)] In those cases: - Temporal logs show
PotentialDeadlockException
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”:
Copy code
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.
If the check pods are not created at all, Airbyte’s worker/Temporal are failing before or while trying to ask Kubernetes to create them. The behavior you describe matches existing reports where: - The user triggers test connection, but: - No
*-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:
Copy code
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:
Copy code
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:
Copy code
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.