You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Include parameter name in JSON Schema error path on unmarshalling #246
I've run into the problem, when I'm not able to show which invalid parameter raised an InvalidSchemaValue.
As InvalidSchemaValue contains a list of schema_errors (List[JsonSchemaValidationError]) I expect to have relative_path / absoulte_path filled for its items. But in reality all items have empty path / relative_path attributes (and absolute_path property).
I've managed to fix this by manually add parameter name as JSON Schem error path as,
try:
returnunmarshaller(value)
exceptInvalidSchemaValueaserr:
# Modify invalid schema validation errors to include parameter nameifisinstance(param_or_media_type, Parameter):
param_name=param_or_media_type.nameforschema_errorinerr.schema_errors:
schema_error.path=schema_error.relative_path=deque(
[param_name]
)
raiseerr
instead of plain,
returnunmarshaller(value)
But would like to have path filled by openapi_core instead.
By the way, do you know how to determine the location (path, body, header, etc.) where the erroring parameter is located? It's not in the error object, either.
I don't think this is resolved. I need to differentiate between schema errors in the request body and in the request parameters (e.g. query string) and there seems to be no info about this on the exception intself nor the schema errors it contains.
Errors are definitely something to improve. However this will be a breaking change and I was waiting for this until I refactor validators. I will add errors refactor to the 0.17 roadmap.
Activity
playpauseandstop commentedon Apr 23, 2020
Similar issue with
CastErrorIt doesn't contain
nameattrib and it is impossible to find out which parameter name resulted casting errorjgod commentedon Dec 24, 2020
Yeah this is a must
jgod commentedon Dec 24, 2020
By the way, do you know how to determine the location (path, body, header, etc.) where the erroring parameter is located? It's not in the error object, either.
osynge commentedon Nov 1, 2021
I feel this is resolved please see my answer to #241
jyggen commentedon Sep 26, 2022
I don't think this is resolved. I need to differentiate between schema errors in the request body and in the request parameters (e.g. query string) and there seems to be no info about this on the exception intself nor the schema errors it contains.
wickedest commentedon Jan 11, 2023
I don't know the code base too well, but I was poking around. Couldn't the parameter name just be mapped to the exception here?
p1c2u commentedon Jan 12, 2023
Errors are definitely something to improve. However this will be a breaking change and I was waiting for this until I refactor validators. I will add errors refactor to the 0.17 roadmap.