Hello Eugen, Thanks for reaching out. We have already had a discussion about this over here <https://apache-airflow.slack.com/archives/C07813CNKA8/p1744891399213529>.
Yes, this change was intentional in Airflow 3. Here’s why: In Airflow 2, the xcom_pull() method allowed pulling XComs by key without specifying task_ids, despite the fact that the underlying DB model defines task_id as part of the XCom primary key. This created ambiguity: if two tasks pushed XComs with the same key, xcom_pull() would pull whichever one happened to be first, leading to unpredictable behavior. Airflow 3 resolves this inconsistency by requiring task_ids when pulling by key. This change aligns with the task-scoped nature of XComs as defined by the schema, ensuring predictable and consistent behavior. We will be fixing this in a later patch release but to answer your question, it is an intended change and is being handled in migration guide via the PR: https://github.com/apache/airflow/pull/49455 Thanks & Regards, Amogh Desai On Tue, Apr 22, 2025 at 2:22 PM Eugen Kosteev <eu...@kosteev.com> wrote: > Hi. > > Sorry, if this was already discussed, I haven't found any trace in github > issues. > > There is the following discrepancy in xcom_pull behavior between Airflow 2 > and 3: > > In case of the xcom_pull with task_ids=["{task_id}"] (list with one value): > - in Airflow 2 LazyXComSelectSequence is returned (with one object) > - in Airflow 3 the value itself is returned > > Details in github issue: > https://github.com/apache/airflow/issues/49540 > > Similar/related issue https://github.com/apache/airflow/issues/46513. > > Since it is a change in the public XCOM interface, it is quite likely that > it will break many DAGs. > We should fix it in Airflow 3 or describe it in the migration guide (if it > is intended change). > > Is it an intended change, or a miss? > > -- > Eugene >
