-
Notifications
You must be signed in to change notification settings - Fork 397
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
Error resolving path in Api Gateway event handler #520
Comments
Hey @marcioemiranda , thanks for raising it! Could you share how you're configuring API Gateway? At a first glance this looks like API GW route matching, so I've created this additional test for use case 2 and it works as expected --- I'm creating an API Gateway with the same path to be on the safe side and report back with a repro repo. def test_nested_dynamic_routes():
# GIVEN
app = ApiGatewayResolver()
event = deepcopy(LOAD_GW_EVENT)
@app.get("/accounts/<account_id>/source_networks")
def get_lambda(account_id: str):
assert account_id == "123"
return {"message": "okay"}
event["resource"] = "/accounts/{account_id}/source_networks"
event["path"] = "/accounts/123/source_networks"
# WHEN calling the event handler
result = app(event, {})
# THEN
assert result["statusCode"] == 200 |
Yup, confirmed, it's a bug --- I can replicate that locally with SAM CLI Test to reproduce the issue - If I define both functions with similar path in the tests it fails exactly as described def test_nested_dynamic_routes():
# GIVEN
app = ApiGatewayResolver()
event = deepcopy(LOAD_GW_EVENT)
event["resource"] = "/accounts/{account_id}/source_networks"
event["path"] = "/accounts/12345/source_networks"
# first rule will be a match, hence not calling the right function
# re.compile('^/accounts/(?P<account_id>.+)$')
@app.get("/accounts/<account_id>")
def get_lambda(account_id: str):
assert account_id == "12345"
return {"message": f"{account_id}"}
# re.compile('^/accounts/(?P<account_id>.+)/source_networks$')
@app.get("/accounts/<account_id>/source_networks")
def get_lambda(account_id: str):
assert account_id == "12345"
return {"message": f"{account_id}"}
# WHEN calling the event handler
result = app(event, {})
# THEN
assert result["statusCode"] == 200 |
@michaelbrewer could you look into it as discussed? @marcioemiranda as a workaround until we fix it, you could change the order of the function definition for the longest/nested being the first one. For example: @app.get("/accounts/<account_id>/source_networks")
def account_nested(account_id: str):
print(f"[ACCOUNT NESTED] Account ID received: --> {account_id}")
return {"account": f"{account_id}"}
@app.get("/accounts/<account_id>")
def account(account_id: str):
print(f"[ACCOUNT SINGLE] Account ID received: --> {account_id}")
return {"account": f"{account_id}"} |
@heitorlessa thanks for the workaround. |
We've got a fix and will ping back once released this week @marcioemiranda ;) If you're curious: #533 |
Opa @marcioemiranda - This is now available in 1.18.0 More details in the release notes: https://github.com/awslabs/aws-lambda-powertools-python/releases/tag/v1.18.0 |
Suppose one has two routes to delete resources like the following:
Use Case 1:
Route in handler
Request
Use Case 2:
Request
Expected Behavior
Expected behavior is that account_id equals 123 in both use cases
Current Behavior
For use case 1 resolver calls the right function and sets account_id = 123
For use case 2, resolver calls the function of use case 1 and sets accound_id = 123/source_networks
Possible Solution
Not sure if this is actually the expected behavior of proxy integration with its greedy regexp or a bug in Lambda Power Tools
Environment
Power Tools version 1.17.1
The text was updated successfully, but these errors were encountered: