Fix rendering the mapped parameters when using expand_kwargs method

[hussein-awala]

closes: #32260

This PR fixes a bug in the mapped operator when using expand_kwargs method.

In the ListOfDictsExpandInput class, the resolve method doesn't filter out string values from the resolved_oids list as we do in the class DictOfListsExpandInput. Consequently, these strings are incorrectly regarded as resolved, even though they are not instances from MappedArgument or XComArg, and their values still match those provided by the user.

This PR removes the literal str values from the list resolved_oids to let the BaseOperator class resolve them.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[hussein-awala]

I have tested this with a testing DAG and confirmed that it works as expected. However, before removing the WIP status, it should also be tested with a taskflow DAG to ensure its compatibility and stability.

[uranusjr]

Tests disagree 🙂

_expand_mapped_kwargs performs some rendering, and the returned OIDs record those already-performed rendering and prevent double-rendering. This broke the mechanism.

[hussein-awala]

_expand_mapped_kwargs performs some rendering, and the returned OIDs record those already-performed rendering and prevent double-rendering. This broke the mechanism.

@uranusjr According to the failed test, we should use the XCom data as it is without resolving it via Jinja. In this case, we cannot consider the reported issue as a bug, because the task result is shared using XCom, and not resolving this result is an expected behavior.

However, supporting passing templates via XCom especially for the mapped operator is a nice feature IMO, for that, I propose adding a new parameter template_in_template to the expand method to tell Airflow whether to resolve the resolved parameters or not.

WDYT?

[uranusjr]

Isn’t the original issue about passing a template as a string literal? That sounds like a reasonable thing, and doesn’t involve XCom.

[hussein-awala]

@uranusjr, I discovered that the issue is just related to the expand_kwargs method. In the ListOfDictsExpandInput class, the resolve method doesn't filter out string values from the resolved_oids list as we do in the class DictOfListsExpandInput. Consequently, these strings are incorrectly regarded as resolved, even though they are not instances from MappedArgument or XComArg, and their values still match those provided by the user.

Could you take another look?

For the new feature "template_in_template" I proposed, I will open a new PR to discuss its idea.