Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to webargs 6.0.0 #132

Merged
merged 3 commits into from Mar 24, 2020
Merged

Move to webargs 6.0.0 #132

merged 3 commits into from Mar 24, 2020

Conversation

lafrech
Copy link
Member

@lafrech lafrech commented Feb 27, 2020

Closes #117.

TODO:

  • Modify pagination schema as unknown=IGNORE to avoid 422ing when other query args are passed on marshmallow 3.
  • Investigate consistency between namespaced webargs validation errors and errors triggered from view func.

@lafrech
Copy link
Member Author

lafrech commented Feb 29, 2020

With webargs 6, errors messages are namespaced by location. Since use_args decorators execute independently and each call will raise on error, the returned error message can't contain errors from several locations. In other words, if there are errors in both query args and body, and query args are parsed first, only errors from query args will be returned, then body errors once query args are fixed.

So first

{"query": {"arg_1": [...], "arg_2": [...]}

then

{"json": {"field_1": [...], "field_2": [...]}}

Errors raised from inside the view are not namespaced. The error message is what the user enters as "errors" parameter to abort (it can be a string, a dict, a list, whatever):

abort(422, errors=...)

Of course, the user can sort of namespace manually by entering whatever he wants as error structure:

abort(422, errors={"database": {"id": "Field must be unique"}})

Namespacing makes sense for webargs validation errors as errors are triggered from a specific location. In fact it is even necessary to discriminate two arguments with same name and different location. But there is no natural namespace for other errors.

Although it might look inconsistent, it is not an issue. This error structure won't be merged with an error structure from webargs validation since webargs validation errors prevent from entering the view.

Related webargs PRs:

marshmallow-code/webargs#420
marshmallow-code/webargs#463

@mekanix
Copy link

mekanix commented Mar 20, 2020

Hello!

First of all, thank you for your swift response about upgrade to webargs 6.0. As FreeBSD maintainer of webargs (and flask-smorest) I updated webargs to 6.0 and now flask-smorest is broken. By no means do I try to rush the solution, but I have to ask if there's any ETA? If you expect to release new version of flask-smorest in next few days, I'll leave the ports/packages as they are, but if not, I would like to revert webargs to latest 5 version so flask-smorest is not broken for users.

@lafrech
Copy link
Member Author

lafrech commented Mar 20, 2020

Thanks for the packaging work.

I shall do this soonish.

@lafrech lafrech added this to the 1.0 milestone Mar 20, 2020
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.

TypeError: use_args() got an unexpected keyword argument 'locations'
2 participants