Wrong routing when using Custom Domain Name

[pismy]

I instantiated the Cookiecutter SAM for Python Lambda functions, embedded the Lambda Powertools as a layer, then deployed it to my AWS account: all good!

Then I tried to configure Custom Domain Name for my API Gateway, and the API internal routing is no longer working.

Calling the API through the default execute-api endpoint ✅

curl https://{my-api-id}.execute-api.{region}.amazonaws.com/Prod/hello/pismy

Returns 200 OK:

{"message": "hello pismy"}

With CloudWatch logs:

{
    "level": "INFO",
    "location": "decorate:345",
    "message": {
        "resource": "/hello/{name}",
        "path": "/hello/pismy",
        "httpMethod": "GET",
       ...
        "queryStringParameters": null,
        "multiValueQueryStringParameters": null,
        "pathParameters": null,
        "stageVariables": null,
        "requestContext": {
            "resourcePath": "/hello/{name}",
            "httpMethod": "GET",
            "path": "/Prod/hello/pismy",
            "stage": "Prod",
            "domainPrefix": "abcd1234",
            "domainName": "abcd1234.execute-api.us-east-1.amazonaws.com",
            "apiId": "abcd1234"
        },
        "body": null,
        "isBase64Encoded": false
    },
    ...
}

Calling the API through the Custom Domain Name 🟥

I first registered the API mapping with path hellopath

curl https://api.mydomain.xyz/hellopath/hello/pismy

Returns 404 Not Found:

{"statusCode":404,"message":"Not found"}

With CloudWatch logs:

{
    "level": "INFO",
    "location": "decorate:345",
    "message": {
        "resource": "/hello/{name}",
        "path": "/hellopath/hello/pismy",
        "httpMethod": "GET",
       ...
        "queryStringParameters": null,
        "multiValueQueryStringParameters": null,
        "pathParameters": null,
        "stageVariables": null,
        "requestContext": {
            "resourcePath": "/hello/{name}",
            "httpMethod": "GET",
            "path": "/hellopath/hello/pismy",
            "stage": "Prod",
            "domainPrefix": "api",
            "domainName": "api.mydomain.xyz",
            "apiId": "abcd1234"
        },
        "body": null,
        "isBase64Encoded": false
    },
    ...
}

Possible Solution

As I'm seeing the log in Cloud Watch, that means the request reaches my Lambda, but it must be the internal routing to the handler function that fails.

@app.get("/hello/<name>")
def hello_you(name):
    # query_strings_as_dict = app.current_event.query_string_parameters
    # json_payload = app.current_event.json_body
    return {"message": f"hello {name}"}

I guess Lambda Powertools must be using message.path or message.requestContext.path from the Lambda event rather than message.resource or message.requestContext.resource to implement the routing.

Unfortunately, when using Custom Domain Names, the message.path contains the API mapping prefix.

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.

[heitorlessa]

Hey @pismy does this feature help?

https://awslabs.github.io/aws-lambda-powertools-python/latest/core/event_handler/api_gateway/#custom-domain-api-mappings

[pismy]

Right, that's what I needed.

I'll close this issue (as it's not a bug), but I would appreciate very much to have your answer on this first @heitorlessa :)

It's a bit sad that the prefix shall be hardcoded in the code.
By the way - depending on the software lifecycle - the same code might need to be deployed first with a prefix staging, and then a prefix prod right ? Then the code shall be rebuilt first... I guess the prefix could be passed as an env variable... 🤔

I'm wondering: wouldn't it be possible to handle Custom Domain Name support implicitly, simply by implementing routing based on message.resource rather than message.path ?

[heitorlessa]

Awesome to hear! On your first question about staging and prod, you can pass multiple values to accommodate that instead of making multiple deployments, since an API can have multiple mappings to the same destination API (payloads in the linked issue) Overall, this was a nightmare if I’m honest since we thought we could support like you suggested but there are differences in REST that were fixed in HTTP API, but then the payload changes slightly, and we support ALB too to make matters worse. We initially had an env var but dropped after finding the other edge cases and didn’t add back in — I think a comma or space delimitation env var values could work here (could you open a feature request please? :)) Here’s the first PR for it with a linked issue and all sample payloads: #579 We’re open for any simplifications if possible despite thinking is one of those unfortunate scenarios where backwards compatibility in all accounts (product, product v2, library) made it difficult to coordinate a good solution.

…

On Fri, 22 Oct 2021 at 12:12, Pierre Smeyers ***@***.***> wrote: Right, that's what I needed. It's a bit sad that the prefix shall be hardcoded in the code. By the way - depending on the software lifecycle - the same code shall be deployed first with a prefix staging, and then a prefix prod right ? Wouldn't it be possible to handle Custom Domain Name support *implicitly* by implementing routing based on message.resource rather than message.path ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#773 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBHIMBQPQTQSWBFIVL3UIE2I7ANCNFSM5GP5IAHQ> .

[pismy]

Thank you so much for your answer.