fix: Restored tracing of ALB event properties #2780
Conversation
Signed-off-by: mrickard <[email protected]>
| } | ||
| const albKeys = [ |
There was a problem hiding this comment.
| } | |
| const albKeys = [ | |
| } | |
| const albKeys = [ |
| } | ||
| const albKeys = [ |
There was a problem hiding this comment.
Please document this as our other event keys are documented.
| 'multiValueQueryStringParameters', | ||
| 'pathParameters' | ||
| ] | ||
| .sort() |
There was a problem hiding this comment.
I recommend listing them in sorted order to avoid the unnecessary sorting operation cost.
| if (!event.multiValueQueryStringParameters) { | ||
| if ( | ||
| !event.multiValueQueryStringParameters || | ||
| Object.keys(event.multiValueQueryStringParameters).length === 0 |
There was a problem hiding this comment.
I don't understand. If we have multiValueQueryStringParameters defined at all, we should not have queryStringParameters defined. So why would we return queryStringParameters if the multi valued property is defined with zero elements?
There was a problem hiding this comment.
In the sample event captured by the customer, both queryStringParameters and multiValueQueryStringParameters were defined, event though each had zero properties. I could see changing this to check for properties in each. The definition of one, though, doesn't exclude the definition of the other, based on the input they've captured.
Description
Filtering of API Gateway v1 vs v2 did not allow for Lambda functions triggered by ALB/ELB. Prior to our most recent change to that filtering, ALB events were traced without explicit filtering. This adds explicit checking for an ALB event type, and allows ALB-triggered web requests to be treated as web transactions.
How to Test
This adds a unit test at
test/unit/server/ess/alb-event.test.jschecking for the expected request properties.Related Issues
Closes NR-341636
Closes #2779
Closes NR-342521