aws_apigateway: RestAPI stage variables not deleted

[dzmitry-rudnouski]

Describe the bug

RestAPI stage has variable, e.g. 'key1:value1'. When you change it to 'key2:value2' CDK creates new variable but doesn't delete old variable.

Expected Behavior

CDK replaces old variable with new variable.

Current Behavior

CDK creates new variable, but doesn't delele old variable.

Reproduction Steps

• Deploy stack:

` from aws_cdk import ( Stack, aws_apigateway as apigateway ) from constructs import Construct

class TestStack(Stack):

def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
    super().__init__(scope, construct_id, **kwargs)

    deploy_options = apigateway.StageOptions(
        stage_name="prod",
        variables={"key1":"value1"}
    )

    api = apigateway.RestApi(self, 'testApi',
        deploy_options=deploy_options
    )
    api.root.add_method('GET')

`

• Replace {"key1":"value1"} with {"key2":"value2"} in code
• Run cdk diff. Diff is ok, it shows key1 should be deleted.

13:23:38 Resources 13:23:38 [~] AWS::ApiGateway::Stage testApi/DeploymentStage.prod testApiDeploymentStageprodCE051BE8 13:23:38 └─ [~] Variables 13:23:38 ├─ [-] Removed: .key1 13:23:38 └─ [+] Added: .key2

• Deploy, then go to AWS console -> old variable is not deleted

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.55.1

Framework Version

No response

Node.js Version

18.0.0

OS

Ubuntu 22.04

Language

Python

Language Version

3.10

Other information

No response

[jashgala]

Was able to reproduce this in typescript as well:

CDK Version: 2.56.0 Sample Code:

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as apig from 'aws-cdk-lib/aws-apigateway'

export class TestCdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const api = new apig.RestApi(this, 'api', {
      deployOptions: {
        stageName: 'dev',
        variables: {
          'k2': 'v2' // previously 'k1': 'v1'
        }
      }
    })

    api.root.addMethod('GET')
  }
}

When I checked the template generated it contained only k2:v2, but on the console it shows k1:v1 and k2:v2.

........
........
........
  "apiDeploymentStagedev96712F43": {
   "Type": "AWS::ApiGateway::Stage",
   "Properties": {
    "RestApiId": {
     "Ref": "apiC8550315"
    },
    "DeploymentId": {
     "Ref": "apiDeployment149F1294f38f93f2666f0c441c06539722c4cca5"
    },
    "StageName": "dev",
    "Variables": {
     "k2": "v2"
    }
   },
   "Metadata": {
    "aws:cdk:path": "TestCdkStack/api/DeploymentStage.dev/Resource"
   }
  }
........
........

Then I went ahead and tried updating the template through the CloudFormation designer and updated it to k3:v3, and sure enough it added k3:v3 instead of replacing it.

Conclusion: This is not an AWS CDK issue, but a CloudFormation issue.

[peterwoodworth]

I've reported this to the service team internally. Will provide updates as they become available (BPL-49911). Thanks for reporting, and @jashgala thanks for confirming 🙂

[jeroenvollenbrock]

@peterwoodworth Do you have any updates on this issue?

[peterwoodworth]

It looks to me like they merged a change linked to the ticket, but they never gave an update. So, it might be fixed? I asked for clarification just now

[github-actions[bot]]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[jeroenvollenbrock]

Sadly, i can confirm the issue still exists. I can however imagine the fix might require “something” to become enabled to avoid a sudden change in behavior?

[peterwoodworth]

Thanks for confirming @jeroenvollenbrock, I'll post an update here as soon as I have one

[eudoroolivares2016]

I'm still seeing this issue. By chance has anyone managed to work around this issue just deleting it from the console? I got here from this issue where it sounds like its cleared from the cloud-stack which then I assume we can just deploy on top of that because serverless would not see any differences between that and the other one

[Lewenhaupt]

Facing a similar issue but instead with models/resources not being deleted.