+1, I think this would help avoid surprises. On Wed, May 13, 2026 at 12:08 PM Przemysław Mirowski <[email protected]> wrote:
> +1 > ________________________________ > From: Jarek Potiuk <[email protected]> > Sent: 13 May 2026 14:19 > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] New Ruff rule to enforce explicit multiple_outputs > when a task outputs a dict > > +1 > > On Wed, May 13, 2026 at 10:28 AM Blain David <[email protected]> > wrote: > > > Wow, just reading it, wasn't even aware of that behavior which is indeed > > "dangerous". I like the proposal, so I'm in favor! > > ________________________________ > > From: Jens Scheffler <[email protected]> > > Sent: Tuesday, May 12, 2026 21:06 > > To: [email protected] <[email protected]> > > Subject: Re: [DISCUSS] New Ruff rule to enforce explicit multiple_outputs > > when a task outputs a dict > > > > EXTERNAL MAIL: Indien je de afzender van deze e-mail niet kent en deze > > niet vertrouwt, klik niet op een link of open geen bijlages. Bij twijfel, > > stuur deze e-mail als bijlage naar [email protected]<mailto: > > [email protected]>. > > > > Sounds like a good idea (also for me) 80% of users (I know) are not > > aware about that feature at all I think. > > > > On 12.05.26 11:53, Wei Lee wrote: > > > Yep, I like this idea. I was quite surprised to see this difference in > > > behavior. > > > > > > Best, > > > Wei > > > > > > Dev-iL <[email protected]> 於 2026年5月12日週二 下午4:05寫道： > > > > > >> Hi everyone, > > >> The context for this discussion is a recent PR which applied > AIR201-like > > >> replacements to the codebase that had to be reverted [1]. > > >> It turns out that using task.output["key"] in place of {{ > > >> xcom_pull('task')['key'] }} is only correct when `multiple_outputs` is > > >> True. Which brings me to the matter at hand: the default value of > > >> `multiple_outputs` is not constant, and is inferred based on the > > presence > > >> of type hints, for example: > > >> > > >> @task > > >> def a(): # multiple_outputs = False > > >> return {"x": 1} > > >> > > >> @task > > >> def b() -> dict: # multiple_outputs = True ← inferred > > >> return {"x": 1} > > >> > > >> While the effects of multiple_outputs are mentioned in the docs [2], > the > > >> effect of the type hint on functionality is, at best, implied [3]. > > Thus, an > > >> unsuspecting user adding type hints might not expect the change in > > >> functionality they will later observe. > > >> > > >> Without getting into whether multiple_outputs inference is good UX, > I'd > > >> like to propose a new Ruff rule, which will detect when a task's > output > > is > > >> either a dict or the task callable is annotated with a dict return > type, > > >> and tell the user to specify the multiple_outputs value explicitly. > > >> Such a rule will have several benefits: 1) Make the intent of the Dag > > >> author explicit; 2) Robustify the code to future changes modifying the > > >> inference logic; 3) Increase awareness of `multiple_outputs`. > > >> > > >> Let me know what you think. > > >> > > >> Best, > > >> Dev-iL > > >> > > >> [1]: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fairflow%2Fpull%2F66712%23issuecomment-4424585768&data=05%7C02%7Cdavid.blain%40infrabel.be%7Ccf82ee9c4af347491e8408deb0598a2c%7Cb82bc314ab8e4d6fb18946f02e1f27f2%7C0%7C0%7C639142095795245565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RjWJY0vK7ZevUQXcXwj6rPJ4CbFraM83DtWM7WXO6AI%3D&reserved=0 > > <https://github.com/apache/airflow/pull/66712#issuecomment-4424585768> > > >> [2]: > > >> > > >> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fairflow.apache.org%2Fdocs%2Fapache-airflow%2Fstable%2Ftutorial%2Ftaskflow.html%23step-2-write-your-tasks-with-task&data=05%7C02%7Cdavid.blain%40infrabel.be%7Ccf82ee9c4af347491e8408deb0598a2c%7Cb82bc314ab8e4d6fb18946f02e1f27f2%7C0%7C0%7C639142095795275996%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pcl0Sj2by9%2FzMbJzYRGb5XSxifhM98spwwCE45L6sb8%3D&reserved=0 > > < > > > https://airflow.apache.org/docs/apache-airflow/stable/tutorial/taskflow.html#step-2-write-your-tasks-with-task > > > > > >> [3]: > > >> > > >> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fairflow.apache.org%2Fdocs%2Fapache-airflow%2Fstable%2Fhowto%2Fcreate-custom-decorator.html%23optional-adding-ide-auto-completion-support&data=05%7C02%7Cdavid.blain%40infrabel.be%7Ccf82ee9c4af347491e8408deb0598a2c%7Cb82bc314ab8e4d6fb18946f02e1f27f2%7C0%7C0%7C639142095795287436%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=717zhm64rvkeb5%2BRFsLJrejcW3Cw6bH5PmWguv8E4D8%3D&reserved=0 > > < > > > https://airflow.apache.org/docs/apache-airflow/stable/howto/create-custom-decorator.html#optional-adding-ide-auto-completion-support > > > > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
