Hello Eugen, Yeah this is a different one. The issue you mention has been added in the migration rules via this PR: https://github.com/apache/airflow/pull/49546 to clarify the migration experience.
Thanks & Regards, Amogh Desai On Tue, Apr 22, 2025 at 5:57 PM Eugen Kosteev <eu...@kosteev.com> wrote: > Hi Amogh. > Thanks for your reply. > > Isn't this a different issue: requiring task_ids parameter or not vs if it > is provided as a list with one element? > > - Eugene > > On Tue, Apr 22, 2025 at 11:02 AM Amogh Desai <amoghdesai....@gmail.com> > wrote: > > > 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 > > > > > > > > -- > Eugene >
