Skip to content

Fix the multi type render for params#66278

Open
shubhamraj-git wants to merge 6 commits intoapache:mainfrom
shubhamraj-git:fix-params
Open

Fix the multi type render for params#66278
shubhamraj-git wants to merge 6 commits intoapache:mainfrom
shubhamraj-git:fix-params

Conversation

@shubhamraj-git
Copy link
Copy Markdown
Contributor

Before -

Type of params -
run_area : ["integer", "string"]
pipelines : ["string", "object"]

but the UI render marks run_area as integer and pipelines as string

image

After -

image
Was generative AI tooling used to co-author this PR?
  • Yes (Claude Code Sonnet 4.6)

  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

@shubhamraj-git shubhamraj-git changed the title Fix the multi type render for aparams Fix the multi type render for params May 2, 2026
Copy link
Copy Markdown
Contributor

@jscheffl jscheffl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK for me but... can you please also add some updates of the now handling into the RST docs describing parameters?

So as far as I see whenever more than one type is defined, the form, will render an object field? How are text values interpreted, e.g. if int+string is allowed and I enter "42". Will this be passed as number or string to the form?

@shubhamraj-git
Copy link
Copy Markdown
Contributor Author

@jscheffl I just pushed a commit, can you recheck again, it will infer type from provided value - for example - 45 as input in UI will be taken as "45" in case of ["string", "object"]

@jscheffl
Copy link
Copy Markdown
Contributor

jscheffl commented May 2, 2026

@jscheffl I just pushed a commit, can you recheck again, it will infer type from provided value - for example - 45 as input in UI will be taken as "45" in case of ["string", "object"]

Yeah. That is a bit better. Still can you add some RST as documentation so that people know about it (and potential limitations that come in your mind). Also as the logic might be prone to regressions, can you make a unit test for mapping with some "supported" examples?

Comment thread airflow-core/docs/core-concepts/params.rst
Copy link
Copy Markdown
Contributor

@jscheffl jscheffl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to add one demo to airflow-core/src/airflow/example_dags/example_params_ui_tutorial.py ?

@shubhamraj-git
Copy link
Copy Markdown
Contributor Author

Would it make sense to add one demo to airflow-core/src/airflow/example_dags/example_params_ui_tutorial.py ?

Added a new example which have multiple multi-type examples

@shubhamraj-git shubhamraj-git force-pushed the fix-params branch 2 times, most recently from a81af47 to aff01e9 Compare May 4, 2026 10:03
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding an example. But oh, we already have soo many and this is overwhelming adding one more. Can you add a new section in example_params_ui_tutorial.py which attempts to collect a lot of options already?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants