-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add documentation for task group mapping #28001
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good!
|
||
.. note:: Arguments passed to a mapped task group is a proxy, not real values | ||
|
||
Different from task functions (``@task``), a task group function is evaluated eagerly, and only once when the DAG is parsed. This means that parameters passed into the function is only a placeholder, and not a real value. For example, this will *not* work: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can elaborate a bit more on this. I feel like this is a important point that may be hard to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. The whole documentation update is great. It's hard to explain it cleared, but maybe siimply state (instead of eagerly
that it is evaluated during parsing, in the scheduler and not during exection in worker?
That could help understand what's going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expanded this section a bit, hopefully it’s a bit easier to understand now.
01d9d7a
to
2ac4689
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really love the attention to possible problems users can have with understanding those, but also what level of details it has for those who try to help the users and need to get the understanding of what are the limitations of current solution without deep diving and getting all the context that sits in the head of those who implemented it.
I think @uranusjr this is a fantastic example on how our docs should look like.
I also took the chance to reorganise existing task mapping documentation a little bit to make the document flows better (for me).
Note that this is intended to be in Airflow 2.6, not 2.5.