Fix clearTaskInstances returning 500 instead of 422 on invalid body

[SreeramaYeshwanthGowd]

POST /dags/{dag_id}/clearTaskInstances returns 500 instead of 422 when the request body is invalid. The ClearTaskInstancesBody validator raised pydantic.ValidationError("..."), which in Pydantic v2 isn't valid and re-raise a TypeError, and the API has no handler for it, so a bad request surfaces as a server error.

Raising ValueError lets Pydantic report it as a 422, matching the sibling PatchTaskInstanceBody validator in the same file. Added a parametrized test covering each invalid body case.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[bugraoz93]

Thanks for your first PR!
I am wondering whether we could update this on the openapi auto exception generation/doc generation to include ValidationError too, otherwise we need to check each and every similar case as they should also have the same behavior

[SreeramaYeshwanthGowd]

@bugraoz93 Thanks! Quick clarification on the mechanism: passing a plain string to Pydantic's ValidationError (raise ValidationError("...")) actually raises TypeError, not a validation error, because the class expects line_errors. Nothing handles that TypeError, so the response comes back as 500 instead of 422. Since the real error is a TypeError and not a ValidationError, a central ValidationError handler would not catch these. Switching to raise ValueError fixes it, and FastAPI already adds 422 to the OpenAPI docs on its own (see create_openapi_http_exception_doc).

I also checked the tree, and the only other place using this pattern is services/public/connections.py:162, which is currently unreachable, so there is nothing else to fix here.

Would appreciate another look when you get a chance. Thanks again!

[SreeramaYeshwanthGowd]

@bugraoz93 @ephraimbuddy whenever you have a moment. Kindly review the PR. Thanks!

[pierrejeambrun]

LGTM, thanks.

[SreeramaYeshwanthGowd]

@pierrejeambrun Thanks for the review. I will raise a follow up PR for core/src/airflow/api_fastapi/core_api/services/public/connections.py

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[pierrejeambrun]

@pierrejeambrun Thanks for the review. I will raise a follow up PR for core/src/airflow/api_fastapi/core_api/services/public/connections.py

@SreeramaYeshwanthGowd I double checked after posting my suggestion and in connection.py the VallidationError is catch and reraised so I think we're fine, no need for an follow up PR.