[BUG] The hash uses the raw, unresolved stage.Variables, so the fix misses the common case where stage variables are parameter-driven. SamApi.to_cloudformation (samtranslator/model/sam_resources.py:1845-1847) runs resolve_parameter_refs over BinaryMediaTypes, Domain and Auth before constructing the generator, but never over self.Variables — it is passed through verbatim (line 1857) and lands on the stage unchanged (api_generator.py:463, and visible in tests/translator/output/intrinsic_functions.json:265 where the variables stay as Fn::Sub/Fn::Join).
So for a template like:
Parameters:
EndpointUri:
Type: String
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: prod
Variables:
EndpointUri: !Ref EndpointUrithe hash input is always {"EndpointUri": {"Ref": "EndpointUri"}} regardless of the deployed parameter value. Deploying with a new value for EndpointUri still yields the same deployment logical id, which is exactly the failure described in #3703: the variable change is not deployed, and UpdateStage points the stage back at the SAM-known deployment. Domain does not have this problem precisely because it is resolved first.
Resolving the variables for hashing purposes would close the gap. Note that Domain is resolved by reassigning self.Domain, which also rewrites the emitted template; for Variables that would inline parameter values into the output AWS::ApiGateway::Stage, so prefer resolving into a separate value used only for the hash rather than mutating self.Variables.
Everything else checks out: stage.Variables is assigned before make_auto_deployable is called (api_generator.py:463 vs 470), that is the only call site, {} and None both fall through the if so no-variable templates keep their logical id, and the 24 fixture updates cover exactly the 8 input templates that set API stage variables across all three partitions, with the logical id, Description digest and Stage.DeploymentId ref updated consistently in each.
Originally posted by @aws-sam-tooling-bot[bot] in aws/serverless-application-model#3991 (comment)
[BUG] The hash uses the raw, unresolved stage.Variables, so the fix misses the common case where stage variables are parameter-driven. SamApi.to_cloudformation (samtranslator/model/sam_resources.py:1845-1847) runs resolve_parameter_refs over BinaryMediaTypes, Domain and Auth before constructing the generator, but never over self.Variables — it is passed through verbatim (line 1857) and lands on the stage unchanged (api_generator.py:463, and visible in tests/translator/output/intrinsic_functions.json:265 where the variables stay as Fn::Sub/Fn::Join).
So for a template like:
the hash input is always {"EndpointUri": {"Ref": "EndpointUri"}} regardless of the deployed parameter value. Deploying with a new value for EndpointUri still yields the same deployment logical id, which is exactly the failure described in #3703: the variable change is not deployed, and UpdateStage points the stage back at the SAM-known deployment. Domain does not have this problem precisely because it is resolved first.
Resolving the variables for hashing purposes would close the gap. Note that Domain is resolved by reassigning self.Domain, which also rewrites the emitted template; for Variables that would inline parameter values into the output AWS::ApiGateway::Stage, so prefer resolving into a separate value used only for the hash rather than mutating self.Variables.
Everything else checks out: stage.Variables is assigned before make_auto_deployable is called (api_generator.py:463 vs 470), that is the only call site, {} and None both fall through the if so no-variable templates keep their logical id, and the 24 fixture updates cover exactly the 8 input templates that set API stage variables across all three partitions, with the logical id, Description digest and Stage.DeploymentId ref updated consistently in each.
Originally posted by @aws-sam-tooling-bot[bot] in aws/serverless-application-model#3991 (comment)