Skip to content

✨ Add support for enabling/disabling input and url fields in validation errors#13657

Closed
kinuax wants to merge 14 commits intofastapi:masterfrom
kinuax:add-flags-to-enable-input-and-url-fields-in-validation-errors
Closed

✨ Add support for enabling/disabling input and url fields in validation errors#13657
kinuax wants to merge 14 commits intofastapi:masterfrom
kinuax:add-flags-to-enable-input-and-url-fields-in-validation-errors

Conversation

@kinuax
Copy link
Contributor

@kinuax kinuax commented Apr 28, 2025 •
edited
Loading

Two new flags for FastAPI and APIRouter instances are proposed: include_error_input and include_error_url. This feature is supported only when using Pydantic v2. Both defaults (True and False, respectively) keep the current FastAPI behavior.

For instance, we could have:

from fastapi import FastAPI

app = FastAPI(include_error_input=True, include_error_url=True)

@app.get("/path1/{path_param}")
def path1(path_param: int):
    return {"path_param": path_param}

@app.get("/path2/")
def path2(query_param: int):
    return {"query_param": query_param}

Therefore, requesting /path1/invalid, /path2/, and /path2/?query_param=invalid would produce errors with proper input and url fields.

@kinuax kinuax changed the title 🔥 Add support for enabling/disabling input and `url fields in validation error 🔥 Add support for enabling/disabling input and url fields in validation error Apr 28, 2025
@kinuax kinuax changed the title 🔥 Add support for enabling/disabling input and url fields in validation error ✨ Add support for enabling/disabling input and url fields in validation errors Apr 28, 2025
@kinuax kinuax mentioned this pull request May 2, 2025
Merged
@kinuax
Copy link
Contributor Author

kinuax commented May 2, 2025

I added docs and tests.

@YuriiMotov YuriiMotov added the feature New feature or request label Jul 16, 2025
@YuriiMotov
Copy link
Member

YuriiMotov commented Jul 16, 2025

For now the ValidationError schema is:
image

It doesn't include any of these fields (just for completeness, ctx field is also missed in schema).
IMO, this should definitely be fixed for input field (should be added as optional).

Having this PR merged we will need to add optional url field as well.

Not sure somebody needs url field. Are there any discussions about this?

@kinuax
Copy link
Contributor Author

kinuax commented Jul 17, 2025

Hi @YuriiMotov, many thanks for checking this PR out.

I share a couple of discussions about this topic:
-#10352
-pydantic/pydantic#7485

Regarding the url field, I think it would be helpful for users who are aware of the underlying Pydantic layer and for cases where the error message is not fully clear, as it would provide a direct link to the relevant documentation.

@github-actions github-actions bot removed the waiting label Jul 17, 2025
@bonastreyair
Copy link

bonastreyair commented Jul 21, 2025

will this ever be reviewed?
I think it would help many people that want full control on the input or url of the schema validation errors when using FastAPI... @YuriiMotov @tiangolo 🙏

@kinuax maybe a rebase and adding that missing 1% of coverage will help, no?

YuriiMotov
YuriiMotov reviewed Jul 21, 2025
View reviewed changes
Copy link
Member

@YuriiMotov YuriiMotov left a comment •
edited
Loading

Choose a reason for hiding this comment

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

It's already possible to exclude input field from the error response by setting the exception handler for RequestValidationError. Adding url field is not trivial task, but I think this is very rare use case.

This PR would bring some convenience for quite rare cases when people need to change this behavior, but it adds 2 additional parameters to FastAPI().
I think, if we add all possible configuration options that people request as parameters, we will end up having very large list of parameters and this will add extra complexity for people to navigate through all these parameters to find the one they need. So, we should only add those that are commonly needed.

Looking at the number of reactions here and on mentioned discussion, I can't say this feature is requested by many people.

See also my previous comment: #13657 (comment)

Having this, I think we should close this PR. I'll pass this to Sebastián, he will review and take a decision.

@kinuax, thanks again for your efforts!

@YuriiMotov

This comment was marked as duplicate.

Sign in to view
@bonastreyair
Copy link

bonastreyair commented Jul 21, 2025

I understand, thanks for your quick response!

What do you think about FastAPI dynamically using the attribute of the schema parameter defined within the pydantic model https://docs.pydantic.dev/latest/api/config/#pydantic.config.ConfigDict.hide_input_in_errors, then we could make it transparent to FastAPI and then be completely configurable using pydantic schemas options.

Would that make sense to have that easier UX?

@YuriiMotov
Copy link
Member

YuriiMotov commented Jul 21, 2025

What do you think about FastAPI dynamically using the attribute of the schema parameter defined within the pydantic model https://docs.pydantic.dev/latest/api/config/#pydantic.config.ConfigDict.hide_input_in_errors, then we could make it transparent to FastAPI and then be completely configurable using pydantic schemas options.

As I understand it, changes on Pydantic's side required to make it working: #10025 (comment)

@kinuax
Copy link
Contributor Author

kinuax commented Jul 22, 2025

Thanks for opening the discussion and sharing your thoughts. 👍

I understand your points regarding complexity and usability. Additionally, I believe that toggling the behavior with flags offers a transparent way to transfer functionality from Pydantic to FastAPI, directly exposing its validation features. This approach enhances Pydantic's visibility and preserves a similar interface across both tools. From a developer experience perspective, it may be more appealing to learn and adjust some arguments when needed rather than having to tweak the exception handler.

Regarding complexity and maintenance, here are a few considerations:
-The arguments do not interact with each other or with any others.
-The core functionality is implemented in the external validator library, which equally supports both input and url.
-The changes only involve passing the arguments and managing the output.

@kinuax
Copy link
Contributor Author

kinuax commented Jul 27, 2025

I have simplified and extended the tests to validate the new feature and maintain 100% coverage. 😄

@tiangolo
Copy link
Member

tiangolo commented Sep 20, 2025

Thanks for the interests! I currently don't think this is necessary in FastAPI itself, I would imagine it's possible to customize it in the specific code base that wants to use it, so that would be a safe alternative.

I also intend to make a refactor for how routers work, allowing people to customize them better, this should also allow implementing this on the user's own code more easily. Although still, the current alternative doesn't seem to be too complicated, so we might be good already.

For now, I'll pass on this one, but thanks! ☕

@tiangolo tiangolo closed this Sep 20, 2025
@kinuax
Copy link
Contributor Author

kinuax commented Sep 22, 2025

@tiangolo, thanks for reviewing and explaining! 👍

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

Reviewers

@YuriiMotov YuriiMotov YuriiMotov left review comments

Assignees

No one assigned

Labels

feature New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@kinuax @YuriiMotov @bonastreyair @tiangolo