[v2-11-test] Ensuring XCom return value can be mapped for dynamically-mapped @task_group's #51668
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix implemented for #51109 in
v2-11
. Closely mirrors #51556.#51109 outlined an issue where trying to dynamically map over an XCom return value using a custom key resulted in unexpected behavior. Rather than leveraging the
list
that was stored at that key, it would dynamically-map TaskGroups using the key-value pairs in the return value itself.This PR addresses this by applying the same logic present in the
_TaskDecorator
class to_TaskGroupFactory
. When attempting to map over a list stored via a keyb
in thedict return value of a Task
t`, the following exception will be raised:Rather than the faulty logic outlined in #51109, the DAG will fail to parse. This matches the same behavior as
@task
. This logic was implemented for both.expand()
and.expand_kwargs()
.To test this, the following DAG was written. The result is now a DAG Import Error, with the stack trace below.