@kapa.ai error after upgrading to airbyte 2.0.1 worker logs

2026-03-01 21:40:30,877 [Workflow Executor taskQueue="ui_commands", namespace="default": 1]	WARN	i.t.i.r.ReplayWorkflowTaskHandler(failureToWFTResult):302 - Workflow task processing failure. startedEventId=3, WorkflowId=discover_4bb34b61-54fc-4fce-be4f-17a33d411c98, RunId=019cab58-7290-74e1-b99b-f70552bb8abf. 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)
...
Caused by: io.temporal.internal.sync.PotentialDeadlockException: [TMPRL1101] Potential deadlock detected. Workflow thread "workflow-method-discover_4bb34b61-54fc-4fce-be4f-17a33d411c98-019cab58-7290-74e1-b99b-f70552bb8abf" didn't yield control for over a second. {detectionTimestamp=1772401228363, threadDumpTimestamp=1772401228369} 

workflow-method-discover_4bb34b61-54fc-4fce-be4f-17a33d411c98-019cab58-7290-74e1-b99b-f70552bb8abf
	at java.base/java.lang.StringBuilder.<init>(StringBuilder.java:106)...

The knowledge sources show the same Temporal error pattern (

InternalWorkflowTaskException

with

PotentialDeadlockException

on

EVENT_TYPE_WORKFLOW_TASK_STARTED

) in two contexts: 1. Closed issue “Temporal context deadline exceeded on EKS” – the stack trace is essentially identical (Temporal workflow task stuck, potential deadlock detected in a workflow thread). [Temporal EKS issue] 2. Open issue “airbyte services stuck where no new job pods are launched” – same Temporal error and deadlock warning, and in that case it manifested as jobs not progressing / pods not being launched. [Jobs stuck issue] However, the knowledge sources do not contain a documented root cause or official fix specifically for Airbyte 2.0.1 or for the

discover_*

workflow you’re seeing. They only show: • Temporal logs warning that “If seen continuously the workflow might be stuck”. • In the “jobs stuck” issue, one user workaround related to dataplane_group / workspace mismatch after upgrading to 2.0: two

dataplane_group

rows existed, jobs were pushed to dataplane A while the workload launcher listened to dataplane B; they fixed it by updating

workspace.dataplane_group_id

to the correct group. [Jobs stuck issue] Given that: • Your log line is the same Temporal deadlock warning pattern. • A very similar symptom after upgrading to 2.0 was caused (for at least one user) by a dataplane configuration mismatch. A concrete check/workaround that is explicitly described in the sources is: 1. In the Airbyte database, inspect dataplane groups:

SELECT * FROM public.dataplane_group;

2. Inspect workspaces and their dataplane group mapping:

SELECT id, organization_id, dataplane_group_id
   FROM public.workspace;

3. If you see two dataplane groups (one pre‑upgrade, one post‑upgrade) and your workspace is pointing to the “wrong” one (i.e., the one not used by the workload launcher), update

workspace.dataplane_group_id

to the correct dataplane group as a workaround. [Jobs stuck issue] Beyond this dataplane/workspace workaround and the fact that Temporal is reporting a potential deadlock, the knowledge sources do not provide further guidance or a confirmed fix for your exact 2.0.1 discovery error. If checking/fixing the dataplane mapping does not help, the next step would be to share full worker + Temporal logs and your deployment details with the Airbyte team (e.g., via GitHub or Slack), referencing that you’re hitting the same Temporal deadlock pattern as in the linked issues. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.