-
Notifications
You must be signed in to change notification settings - Fork 402
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
Bug: get_field_info_and_type_annotation doesn't respect tuple return types #5034
Comments
Thanks for opening your first issue here! We'll come back to you as soon as we can. |
Hey @philiptzou! Thanks for opening this discussion because I see room to improve our documentation. Actually this is not a bug, this is an expected behavior but I agree that it's not very clear in our documentation. Before agreeing with next steps, let me explain why this is working as expected. Prior to PR #1853, customers who wanted to set a specific response code for methods must respond to a method using the Response object or a dict like Your code should be something like this: @app.get('/foobar')
def foobar() -> dict:
return Result(payload='foobar'), 201 While I don't consider this a bug, I do see that we need to improve our documentation to make this clearer and prevent customers from interpreting it as an error. I'll add the documentation label to this issue and think about a solution. In the meantime, please test it with the code above and see if it works. |
Hey @philiptzou! Please reopen if you have any additional questions. Thanks |
|
Thanks. But for project that have strict typing lint enabled, this solution will trigger linter error by tools such as I'll re-open this issue. |
Hi @philiptzou, thanks for replying. although we try to make the project as strictly typed as possible, unfortunately we cannot guarantee that we are fully typed, so things like this may happen somewhere in the project. I don't know if we have a solution for this, since we need to convert this into a json object and this not return tuple. |
@leandrodamascena My current work around is still returning |
@philiptzou Is it possible to share a branch with this code? I can check it and might incorporate in our codebase + tests. Reopening this issue. |
@leandrodamascena Sorry I missed the last message you posted after the re-opening. Unfortunately the repository is private and I can not share it. However, this is basically the workaround I took (please compare with the original code snippet): from pydantic import BaseModel
from aws_lambda_powertools.event_handler import Response # <-- change 1
from aws_lambda_powertools.event_handler import ALBResolver
app = ALBResolver(enable_validation=True)
class Result(BaseModel):
payload: str
@app.post('/foobar')
def foobar() -> Response[Result]: # <-- change 2
return app._to_response( # <-- change 3
(Result(payload='foobar'), 201)
)
def test_foobar():
response = app.resolve({
'path': '/foobar',
'httpMethod': 'POST',
'queryStringParameters': {},
'headers': {}
})
assert response['statusCode'] == 201 |
Oh I also just remembered that I can submit a PR. If you can help working on the test cases I'll do it soon. |
Hey @philiptzou! Yeah, please submit the PR and we can work together in the tests. |
Expected Behaviour
The
get_field_info_and_type_annotation
function should respecttuple
response types since it is supported since 2.7.0. See #1845 and #1853.Current Behaviour
Validation error (HTTP 422) happens when the endpoint function returning type annotation is a tuple, if we had
enable_validation=True
for OpenAPI validation.Code snippet
Instead of
201 Created
, the endpoint currently returns 422 error with following body:Possible Solution
Update here to support tuple type for a response. In addition, distinguishing
is_response_param
is necessary for avoiding changing behaviors for other types of annotations.powertools-lambda-python/aws_lambda_powertools/event_handler/openapi/params.py
Lines 969 to 987 in 8251bb0
Steps to Reproduce
Please see above code snippet.
Powertools for AWS Lambda (Python) version
latest
AWS Lambda function runtime
3.11
Packaging format used
PyPi
Debugging logs
No response
The text was updated successfully, but these errors were encountered: