agent mis-read airflow xcom and reported a failed task

TL;DR

The agent treated an XCom value as the task verdict: a None, a missing key, or a stale value read as failure. Task instance state is the verdict; XCom is just data the task left behind. Check state first, then interpret the XCom value in context. A missing XCom on a successful task is normal, not a failure.

agent mis-read airflow xcom and reported a failed task

Use this when

• An agent reports a task failed based on XCom contents.
• The task state is actually success.
• XCom is None, missing, or stale and the agent panicked.

Not for this skill when

• The task genuinely failed. Read the failure.
• XCom is missing on a failed task. That is consistent, not a misread.

Steps

1. Query the task instance state first. Note the state. Verify: the verdict is established
2. Read the XCom value with its key, task id, and dag run context. Note the full coordinates. Verify: the read is precise
3. Interpret the value against the state: None on success is just no data pushed. Note the interpretation. Verify: the value is contextualized
4. Fix the agent: state first, XCom second, never XCom alone. Note the new order. Verify: the logic is corrected
5. Add regression cases: success with no XCom, success with None, failure with XCom. Note the tests. Verify: the cases are pinned

Variant phrasings

airflow xcom none vs missing

The distinction phrasing.

agent read xcom task state

The agent-shaped search.

Compatibility: Airflow 2.x XCom and task instance states via the REST API.

Why it happens

XCom is a key-value side channel, not a status channel: tasks push what they want, including nothing. Agents that read XCom as a verdict confuse the absence of data with the presence of failure. The task instance state exists precisely to be the verdict, maintained by the scheduler, unambiguous. This misread is a small instance of a general rule: derive conclusions from the system's own status fields, not from interpreting its data fields as status.

Edge cases / pitfalls

• A task can push XCom and then fail, leaving a stale success-looking value. State disambiguates; the value's timestamp helps.
• xcompull across dag runs needs includeprior_dates. A None from the wrong run scope is a scope bug, not a failure.
• Custom XCom backends can return deserialized oddities. Validate the read path before blaming the task.
• Sensors and operators that never push XCom succeed silently. Expect missing XCom on many successful tasks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8YPAI9VIJjuuw7OKdOkww