Add support for Amazon API Gateway payload format version 2.0 (for HTTP API and Lambda function URLs)

[kiwi-26]

Amazon API Gateway has 2 versions of payload format.

Using API Gateway REST API, lambda function receives event (payload version 1) and bolt can handle the event. But via API Gateway HTTP API or Lambda function URLs, lambda functions receives event (payload version 2) and bolt can't handle some events. For example, because path field is changed (path -> rawPath), bolt don't handle events used slack event path /slack/events.

Please support both payload format version 1 and 2.

Payload format difference document: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[filmaj]

Seems like a reasonable feature request, though I think this is more of a userland / community concern than a Slack concern.

Bolt uses a pattern we call 'receivers' that decouples the typical event-driven application design of a bolt app from some of the implementation details (like e.g. AWS services to host the app on and their differences). You can implement your own receiver: we have a Receiver interface you can follow, and all of the built-in Receivers we provide are implemented using this pattern.

That said, we cannot guarantee that we will implement this. While I agree it is a nice feature request, I do not think it is reasonable for Slack to implement a receiver for every single type of deployment option available to developers - there are countless ways to deploy applications and Slack cannot possibly satisfy all of them.

[kiwi-26]

Thank you for your comment. I understand and agree that Slack shouldn't try to implement a receiver for every single type of deployment option.

If I follow that policy, the number of supported vendors will increase, so even if I write code to support this, would it be better not to create a pull request?

[seratch]

Hi @kiwi-26, thanks for sharing this. Generally speaking, as Fil mentioned, we don't support various patterns of other platform use case scenarios. That said, bolt-python already supports both v1 and v2, so we (at least myself) are happy to make the necessary changes to enable bolt-js to function with both formats.

I can look into the details sometime soon, but could you please share a bit more details of the issue you've experienced?

• Are you using AwsLambdaReceiver? Or are you trying to build your own receiver?
• If you're using AwsLambdaReceiver, which line of code fails to function?

You mentioned path vs rawPath, but AwsLambdaReceiver does not pass the path value to App instance. Sharing what actually happens would be helpful for us to understand the issue correctly (I will try to reproduce the issue on my end too, but your insights would be appreciated!)

Also, if you're happy to use your time for sending a pull request to resolve this, it'd be greatly appreciated too!

[filmaj]

That said, bolt-python already supports both v1 and v2

Ah, my mistake. I did not realize this. Please disregard my previous comment about this being a userland concern; if other bolt frameworks already support REST API v2, then bolt-js should as well.

[kiwi-26]

Thank you, @filmaj @seratch ! And I'm sorry, referring to the @seratch comment, I tried deleting the code that repacks Payload v2 events to v1 again, and it worked correctly. So bolt-js already worked fine with v2 payloads too. Sorry for taking your time.

One inconvenience I found was that because the AwsEvent type was designed for Payload v1, I couldn't directly use objects of the APIGatewayProxyEventV2 type or LambdaFunctionURLEvent type as the first argument of the handler. It would be nice if it were possible to specify both payload v1 and v2 objects by defining only the minimum necessary items.

[seratch]

Thank you for confirming that the receiver works runtime. Regarding the TypeScript types, you are correct that the argument interface should be enhanced to be compatible with both v1 and v2. To resolve this, the type can be a union type instead. We'll improve this in a future release. If you are happy to send a pull request for it, we would love to have your contribution!

[filmaj]

FYI we are discussing in this section of the bolt-v4 pull request being reviewed on how to address this problem; @kiwi-26 if you have opinions or suggestions, feel free to take part in the discussion 🙇

[filmaj]

FYI a release candidate with this fix is available in @slack/bolt@4.0.0-rc.2. It is a pre-release, however, so you will need to explicitly install that version, and since it is a breaking change, it is included with other breaking changes. However, there is a migration guide available to help guide you through the changes requiring other modifications to your app.

[filmaj]

This fix is now available in bolt v4, which was just released to npm.