added unique token to deployment logical id

[eahefnawy]

Adds a unique timestamp token to the APIG deployment logical id to prompt AWS CF to restart deployment.

[flomotlik]

LGTM

[wedgybo]

I'm looking over the PR on a phone but I'm pretty sure this won't cover removed functions

[flomotlik]

@wedgybo yup it looks like its unreliable for removing methods from a deployment. It reliably adds them now due to the dependsOn, but the takes old methods with it most of the time as old methods are still available in the resources while the new deployment is happening. Just as you described in the issue. I'll bring this up with AWS, because this is really seems like a bug in the Cloudformation implementation now.

[wedgybo]

Yea the problem is it works on a diff so you need to deploy after clean up.

I THINK the solution is to create the stage without relying on the deployment to do it for you, if you want to do it all in one swoop. So it would be worth asking about that approach?

[flomotlik]

@wedgybo yup reached out, let see what comes back. but at least we can deploy in general now.

[kkozmic-seek]

What problem does this solve (the unique Deployment logical ID specifically)? Having multiple Deployments with unique name kills ability to specify StageDescription as now subsequent deployments fail with "StageDescription cannot be specified when stage referenced by StageName already exists"

[pmuens]

Hey @kkozmic-seek this is a kind of workaround so that API Gateway knows that a new deployment should be done / something in the config was updated.

API Gateway won't pick up the updates you've specified if this is missing.

[kkozmic-seek]

hey @pmuens thanks for the response.

So let me see if I understand correctly what you're saying.

If we have hardcoded Deployment logical ID that we reuse every time API Gateway will not deploy subsequent changes to the API? That feels... counterintuitive.

Also, if that's the case, why was it only changed late in the process for Serverless (this PR was only merged few months ago). Wouldn't that issue be visible much sooner than that?

[pmuens]

@kkozmic-seek correct.
The re-deployment only failed sometimes as far as I remember. Don't know which edge cases were affected but maybe @eahefnawy knows more.

The API Gateway team is aware of this and they're looking into it to fix it.

[kkozmic-seek]

Ok, I opened a ticket with AWS about this as well, and I'm looking at some workarounds for my underlying issue (API Gateway caching support) which looks like may be solved by pulling Stage into it's own explicit resource in CFN and pointing from Stage to Deployment.

I have some options to try so hopefully one of them does work reliably