fix(api): return 422 for missing QueryParams fields

[axelray-dev]

Description

• Summary of the change/ bug fix.
  • When a fetcher raises a pydantic ValidationError for a QueryParams model and a required field is absent from the request query string, the API now returns HTTP 422 with query-scoped detail locations instead of HTTP 500 Unexpected Error.
• Link [Bug] Fetcher-level pydantic ValidationError returns 500 "Unexpected Error" instead of 422 (e.g. bls_search without category) #7629
• Relevant motivation and context.
  • Missing required query fields never appear in request.query_params, so the previous all_in_query gate fell through to the generic 500 path. That mismatched FastAPI-layer 422 behavior for the same class of client error (e.g. bls_search without category).
• List any dependencies that are required for this change.
  • None.

How has this been tested?

• Unit tests for ExceptionHandlers.validation covering:
  • Missing QueryParams field not present in query_params -> 422 with loc starting with query
  • ResponseValidationError still 422
  • Non-QueryParams ValidationError still 500
• Command:
  • PYTHONPATH=openbb_platform/core pytest openbb_platform/core/tests/api/test_exception_handlers.py
  • Result: 3 passed
• Ensure all unit and integration tests pass.
  • Focused unit tests pass locally; full suite left to CI.

Checklist

• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have adhered to the GitFlow naming convention and my branch name is in the format of feature/feature-name or hotfix/hotfix-name.
• I ensure that I am following the CONTRIBUTING guidelines.
  • (If applicable) I have updated tests following these guidelines.

[CLAassistant]

All committers have signed the CLA.

[anujbolewar]

Sensibly dropping the all_in_query condition since every QueryParams validation should indeed surface as a query-param error. The one case to double check: a QueryParams-backed model can also be used to bind a request body in some routes, and for those the detail will now wrongly claim it sits in query params — confirm the involved routes all read from the query string, otherwise keep a guard that checks whether the request carried a body.