GitHub user pykenny edited a comment on the discussion: Cannot use custom XCOM keys in task mapping expand function
>From >[how](https://github.com/apache/airflow/blob/ea4b6c2ee755db4c3b7e0e1c48a768ab7d7aa977/airflow/models/taskinstance.py#L1186) > a task instance decides what kind of downstream mapped tasks to be >dynamically created, the decision to force using "`return_value`" in the XCom >is based on the fact that a task instance >[uses](https://github.com/apache/airflow/blob/ea4b6c2ee755db4c3b7e0e1c48a768ab7d7aa977/airflow/models/taskinstance.py#L788) > value [returned from the Python >callable](https://github.com/apache/airflow/blob/ea4b6c2ee755db4c3b7e0e1c48a768ab7d7aa977/airflow/models/taskinstance.py#L763) > within the operator, instead of full XCom content of the task instance, to >decide what should be mapped to the downstream. For most decorated tasks I >think it might not be the problem, but for traditional task objects base on >`BaseOperator` and decorated tasks that calls `TaskInstnace.xcom_push()` >internally, extra values can be added to XCom output during task execution and >these key-value pairs will be missed. That said, adding extra logic to pull full XCom output from the backbone database again may help with this use case, but that depends on when XCom output of a task is "determined/stablized", and whether it's reasonable/feasible to do that from current task execution workflow design. GitHub link: https://github.com/apache/airflow/discussions/27211#discussioncomment-12078483 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
