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 tasks objects base on >`BaseOperator` and decorated tasks that calls `TaskInstnace.xcom_push()`, >extra values can be added to its XCom output during task execution. 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", and whether it's reasonable/feasible to do that from current task execution workflow. 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]
