-
Notifications
You must be signed in to change notification settings - Fork 413
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
fix(openapi): validate response serialization when falsy #6119
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #6119 +/- ##
===========================================
- Coverage 96.28% 96.19% -0.10%
===========================================
Files 235 235
Lines 11229 11226 -3
Branches 830 828 -2
===========================================
- Hits 10812 10799 -13
- Misses 327 337 +10
Partials 90 90 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @anafalcao! Another super nice PR to fix an important bug! I left some comments to avoid any breaking change from our side.
aws_lambda_powertools/event_handler/middlewares/openapi_validation.py
Outdated
Show resolved
Hide resolved
tests/functional/event_handler/_pydantic/test_openapi_validation_middleware.py
Outdated
Show resolved
Hide resolved
|
Issue number: #5887
Summary
Changes
This PR fixes a bug where OpenAPI validation was not validating response serialization when the response body was a falsy value (e.g., False, 0, empty string, etc.), making the the response body validation is more strict.
It also removes Pydantic V1 compatibility.
User experience
Before:
After:
Checklist
If your change doesn't seem to apply, please leave them unchecked.
Is this a breaking change?
RFC issue number:
Checklist:
Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.