feat(openapi): enhance support for tuple return type validation

[philiptzou]

Issue number: #5034

Summary

Changes

This PR fixes the issue that OpenAPI validation failed to validate two-element tuple returns, which is allowed by the APIGateway.

User experience

Below test fails before this PR but passes after this PR:

from pydantic import BaseModel
from aws_lambda_powertools.event_handler import ALBResolver

app = ALBResolver(enable_validation=True)


class Result(BaseModel):
    payload: str


@app.post('/foobar')
def foobar() -> tuple[Result, int]:
    return Result(payload='foobar'), 201


def test_foobar():
    response = app.resolve({
        'path': '/foobar',
        'httpMethod': 'POST',
        'queryStringParameters': {},
        'headers': {}
    }, None)
    assert response['statusCode'] == 201

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• Meet tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics

Is this a breaking change?

RFC issue number:

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

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.

[boring-cyborg]

Thanks a lot for your first contribution! Please check out our contributing guidelines and don't hesitate to ask whatever you need.
In the meantime, check out the #python channel on our Powertools for AWS Lambda Discord: Invite link

[leandrodamascena]

Hey @philiptzou! Thanks a lot for submitting this PR. 🚀

I see we have some problems with type checking that is breaking the CI and we need to address them before I make a final review.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.24%. Comparing base (d12babf) to head (00d110d).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #5997   +/-   ##
========================================
  Coverage    96.24%   96.24%           
========================================
  Files          234      234           
  Lines        11017    11024    +7     
  Branches       798      800    +2     
========================================
+ Hits         10603    10610    +7     
  Misses         327      327           
  Partials        87       87           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[leandrodamascena]

Hey @philiptzou! Thanks for working on this PR and addressing the feedback!

I have a feeling that this PR can breaks the validation for people using dict as return. But I think this is really a bug that we need to fix.

e.g

@app.get('/foobar')
def foobar() -> dict:
    return Result(payload='foobar'), 201

APPROVED!

[boring-cyborg]

Awesome work, congrats on your first merged pull request and thank you for helping improve everyone's experience!

[philiptzou]

Hey @philiptzou! Thanks for working on this PR and addressing the feedback!

I have a feeling that this PR can breaks the validation for people using dict as return. But I think this is really a bug that we need to fix.

e.g

@app.get('/foobar')
def foobar() -> dict:
    return Result(payload='foobar'), 201

APPROVED!

Well, I don't think this PR will break dict as return since it still falls in the else branch. This example still work, but it irritates mypy anyway.