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

openapi3filter.RequestError message customize #465

Open
mpasokolov opened this issue Dec 18, 2021 · 3 comments
Open

openapi3filter.RequestError message customize #465

mpasokolov opened this issue Dec 18, 2021 · 3 comments

Comments

@mpasokolov
Copy link

Hello everyone.

Can you help me. Can i change default message in error.

Example: "parameter "id" in query has an error: number must be most 1"

@fenollp
Copy link
Collaborator

fenollp commented Dec 18, 2021

Is this what you meant? #466

@mpasokolov
Copy link
Author

mpasokolov commented Dec 18, 2021

Thank you for answer, but i mean i want return other message. For example:
as is: "parameter "id" in query has an error: number must be most 1"
to be: "incorrect value"(for example, real message will be in russian).

@mpasokolov mpasokolov changed the title *openapi3filter.RequestError message customize openapi3filter.RequestError message customize Dec 18, 2021
@fenollp
Copy link
Collaborator

fenollp commented Dec 18, 2021

I see. There have been similar inquiries I think for the purpose of rewriting the error message and also to generally uniquely identify the returned error.

I see a few ways of going at this:

  1. using some i18n library and language files, so users could define their own file or use the default (today's) one
  2. define unique string types for each schema/filter error format so users can type-switch on them. Or export all format strings used in schema error reasons and create a function that finds the format string from the error's reason
  3. Do something similar to https://github.com/getkin/kin-openapi/blob/f13ef7f1c13bf20978f006d7002d0ea96c03cc14/openapi3filter/validation_error_encoder.go

A generic way of identifying / matching schema error messages would be useful to many users of this lib and so I am interested in helping move this forward.

Today error messages are not stabilized meaning the format string can change completely from one release to another. Especially considering the eventual rewrite of the data validation part: #412

To me the first option in this list would be the more robust one, especially if there's a way of knowing whether a file's entry is missing or is unused.

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

No branches or pull requests

2 participants