Skill for fixing the issue https://github.com/airflow-s/airflow-s/pull/271
On Wed, Apr 15, 2026 at 3:34 PM Jarek Potiuk <[email protected]> wrote: > > This was ambiguous regarding the value you wanted to retrieve and the > intended change. > > While I see why we cannot (should not) bring back the "exact" behaviour, I > think we could - potentially at least - make it non-ambiguous and > predictable by defining the semantics and ordering and selecting the first > one. And - I think - we do not **have** to bring it back in this particular > method. Maybe we can just a new method call with defined ordering and > semantics - behaving predictably, similar to Airflow 2—and clearly defined > semantically. That would at least give people an easier way to migrate? > > While I think the cat if out-of-the bag and we cannot truly revert the > change (because that would again potentially affect 3.0 - 3.2 users) - but > we could at least make it easier for people to cope with it without too > much hassle while waiting for the task state to be available in this > particular case? > > Just a thought I had - ... listen to your users and do things easier for > them - without breaking our SemVer promises. > > J. > > > > On Wed, Apr 15, 2026 at 3:20 PM Foldvari, Gyorgy via dev < > [email protected]> wrote: > >> I do not want to use XCom for managing task state. It was just a very >> simple - and seemingly misleading - example to explain the original >> behavior. >> >> I gave details about valid use cases and issues caused by this change in >> the behavior, in my original post. Those are not addressed by the AIP you >> are referring to. >> >> But that AIP would definitely address another valid use case what I am >> missing especially for implementing stateful sensors, so I really hope it >> goes through and gets implemented. >> >> >> Information Classification: GENERAL >> -----Original Message----- >> From: Ash Berlin-Taylor <[email protected]> >> Sent: Wednesday, April 15, 2026 14:49 >> To: [email protected] >> Subject: Re: [DISCUSS] Reconsidering `xcom_pull(task_ids=None)` behavior >> change in Airflow 3 >> >> [You don't often get email from [email protected]. Learn why this is >> important at https://aka.ms/LearnAboutSenderIdentification ] >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know >> the content is safe. >> >> >> This was ambiguous as to what value you wanted to get, and an intended >> change. >> >> If you want this sort of behaviour, then you probably want to look at >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-103%3A+Task+State+Management >> which provides a dedicated way to manage state without many of the quirks >> of XCom interface as it stands today. Reading between the lines, I think >> this API describes what you want? >> >> -ash >> >> > On 15 Apr 2026, at 12:45, Foldvari, Gyorgy via dev < >> [email protected]> wrote: >> > >> > I see where the confusion is coming from, it is my mistake. Sorry about >> that. >> > >> > To clarify, I am taking about the use case where the key parameter is >> passed but the task_ids parameter is not or it is None. >> > >> > -----Original Message----- >> > From: Foldvari, Gyorgy via dev <[email protected]> >> > Sent: Wednesday, April 15, 2026 13:42 >> > To: [email protected] >> > Cc: Foldvari, Gyorgy <[email protected]> >> > Subject: RE: Re: [DISCUSS] Reconsidering `xcom_pull(task_ids=None)` >> > behavior change in Airflow 3 >> > >> > CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know >> the content is safe. >> > >> > >> > The original behavior is to return the most recent value put by any >> upstream task of the same run. Not all the values, only the recent one. >> > Supposing that there are multiple tasks pushing values to XCom in this >> order: >> > Task1: ti.xcom_push(key="example", value=1) >> > Task2: ti.xcom_push(key="example", value=2) >> > Task3: ti.xcom_push(key="example", value=3) Then in a downstream task >> ti.comm_pull(key="example") returns 3. >> > I do not propose to change this behavior. >> > >> > On 2026/04/14 16:09:05 Daniel Standish via dev wrote: >> >> So the behavior before would be that it would return all xcom values >> >> that were emitted from the present run? >> >> >> > >> > >> > ________________________________ >> > >> > Information regarding MSCI's processing of personal data may be found >> > at http://www.msci.com/privacy-pledge. This email message and any >> attachments >> > are for the sole use of the intended recipients and may contain >> > proprietary and/or confidential information which may be privileged or >> > otherwise protected from disclosure. Any unauthorized review, use, >> > disclosure or distribution is prohibited. All rights and remedies are >> > reserved. If you are not an intended recipient, please contact the >> > sender by reply email and destroy the original message and any copies >> > of the message as well as any attachments to the original message. >> > Local registered entity information: >> > https://www.msci.com/local-registered-entities >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> >> ________________________________ >> >> Information regarding MSCI’s processing of personal data may be found at >> http://www.msci.com/privacy-pledge. This email message and any >> attachments are for the sole use of the intended recipients and may contain >> proprietary and/or confidential information which may be privileged or >> otherwise protected from disclosure. Any unauthorized review, use, >> disclosure or distribution is prohibited. All rights and remedies are >> reserved. If you are not an intended recipient, please contact the sender >> by reply email and destroy the original message and any copies of the >> message as well as any attachments to the original message. Local >> registered entity information: >> https://www.msci.com/local-registered-entities >> >
