HttpApi did not apply changes during a stack update.

[brysontyrrell]

Description:

I'm working on switching over one of my Rest APIs in a service to HTTP API. I had it initially deployed with three routes each with their own Lambda function. I then pushed an update that condensed those three Lambdas to a single one with three events attached to it for the route.

The HTTP API correctly removed the old route-integrations but then didn't apply any of the new ones. The API and the Lambdas were all created, but none of the integrations were.

When view the $default stage in the console I could see a message that the deployment failed as there were no routes configured, but this deployment failure within API Gateway did not report back to CloudFormation where it reported everything had deployed successfully.

Deleting and re-creating the CloudFormation stack brought up the HTTP API correctly with all of the route-integrations configured.

Steps to reproduce the issue:

1. Create an HTTP API with multiple Lambdas/routes. Deploy it.
2. Update the HTTP API to use a single Lambda with all three routes attached in the Events. Deploy the change.

Observed result:

The HTTP API loses all routes and has no integrations configured.

Expected result:

The HTTP API removes the old route-integrations and correctly configures the new ones.

[keetonian]

@brysontyrrell it appears that there's a bug in CloudFormation/ApiGateway that causes this silent failure. For now, we're exposing FailOnWarnings, which should be set to true to at least cause a rollback instead of a silent failure. We're also adding support for reading and adding path parameters, which should help with this problem (if not fully fix it).

[ShreyaGangishetty]

#1509 and #1510

[brysontyrrell]

Thanks @keetonian

I don't think it's related to the deployment issue, but I also came across a problem with HTTP API event payloads. This is what I was getting from my HTTP API in Lambda:

{
    "version": 1.0,
    "resource": "/v1/bdb00c02-9147-4c41-879a-25fef3caaf81/software",
    "path": "/v1/bdb00c02-9147-4c41-879a-25fef3caaf81/software",
    "httpMethod": "GET",
...

And it should be like this (as it is with REST APIs):

{
    "version": 1.0,
    "resource": "/v1/{contributor_id}/software",
    "path": "/v1/bdb00c02-9147-4c41-879a-25fef3caaf81/software",
    "httpMethod": "GET",
...

The HTTP API event is passing the client inputted path into the resource key.

[keetonian]

@brysontyrrell thanks again! I discussed that with ApiGateway, we'll see what we can do!