Thank you. On Tue, Apr 22, 2025 at 2:31 PM Amogh Desai <amoghdesai....@gmail.com> wrote:
> 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 > > > -- Eugene
