Bug: Powertools Bedrock Resolver truncates parameters with commas

[mkkatica]

Expected Behaviour

Given an input:

{
        "apiPath": "/sql-query",
        "httpMethod": "POST",
        "inputText": "<some irrelevant text>",
        "actionGroup": "test-group",
        "parameters": [
        {
            "name": "query",
            "type": "string",
            "value": "SELECT a.source_name, b.thing FROM table"
        }]
}

The expected parameters passed to the function registered at the endpoint should include the entire query:

@app.post("/sql-query...)
def my_func(query: Annotated[str,...]):
    print(query)

Current Behaviour

Currently, the above code prints "SELECT a.source_name". I've validated that it works correctly with queries without commas. I am unaware of any other characters that cause this behavior.

Code snippet

See above. This can be easily recreated by passing a Bedrock action group query parameter with a comma in it to the resolver.

Possible Solution

This may be related to how the resolver inherits from the ApiGateway resolver and passes the parameters as query parameters.

Steps to Reproduce

1. Create a Bedrock Agent Resolver instance and add a POST route with a string parameter
2. Pass a valid minimum test payload to the handler instance with a parameter value including a comma, such as a complex SQL query
3. Check the parameter as passed to the route function

Powertools for AWS Lambda (Python) version

latest

AWS Lambda function runtime

3.12

Packaging format used

Lambda Layers

Debugging logs

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #python channel on our Powertools for AWS Lambda Discord: Invite link

[leandrodamascena]

Hi @mkkatica, thanks for opening this issue! I think I know what's going on here! When we parse the event that tries to determine if the request contains a multi-valued parameter, we are incorrectly parsing data where the comma is actually expected, as in your case.

I need to see how to fix this, but will add in our backlog to take a look this week.

[mkkatica]

Thanks @leandrodamascena! I was able to work around this by reading the event directly in my route function using app.current_event for now, but it will be nice to have it parse correctly.