ApiGatewayDeployment.make_auto_deployable does not account for API Stage Variables

[majic]

Stage variable updates will cause an API Gateway UpdateStage call during SAM API stack deployment. However, since API Stage variables are not considered as hash input to ApiGatewayDeployment.make_auto_deployable, an update to a SAM API Stage can be made without a new deployment.

serverless-application-model/samtranslator/model/apigateway.py

Lines 95 to 103 in 17000c1

	def make_auto_deployable( # noqa: PLR0913
	self,
	stage: ApiGatewayStage,
	openapi_version: Optional[Union[Dict[str, Any], str]] = None,
	swagger: Optional[Dict[str, Any]] = None,
	domain: Optional[Dict[str, Any]] = None,
	redeploy_restapi_parameters: Optional[Any] = None,
	always_deploy: Optional[bool] = False,
	) -> None:

This means

1. The API Stage variables updates are not 'deployed',
2. UpdateStage will reset the Active API Deployment to it's last known good API Deployment ID. If you have made other non-SAM managed deployments since your last SAM managed deployment, a latest change with just API Stage Variable changes will revert the active deployment Id to the last known good deployment. This effectively reverts your latest changes made outside of the SAM managed changes.

---

My team uses scripts to adjust the API Resource Policy (to onboard new clients), then deploy those authz changes using create-deployment, The above issue 2) recently caused an issue where our latest onboarding Resource Policy changes were no longer active after an API Stage Variable only change SAM deployment

REPRO:

1. Deploy SAM Api
2. Manually update the API Resource Policy
3. Manually deploy the API
4. Update SAM definition to add / change an API Stage Variable
5. Deploy the updated SAM definition

OBSERVE:

1. Step 5) creates an CFN Changeset with the update to the API Stage variables.
2. Processing that change set produces a Cloud Trail UpdateState Event where you can see both the new variable details, ,but also the 'reset' of the deploymnent value to something old.

IMPACT:
Your manual policy update step 2) is no longer active.

[majic]

Regarding the code using make_auto_deployable

serverless-application-model/samtranslator/model/api/api_generator.py

Lines 431 to 451 in 17000c1

	stage = ApiGatewayStage(stage_logical_id, attributes=self.passthrough_resource_attributes)
	stage.RestApiId = ref(self.logical_id)
	stage.update_deployment_ref(deployment.logical_id)
	stage.StageName = self.stage_name
	stage.CacheClusterEnabled = self.cache_cluster_enabled
	stage.CacheClusterSize = self.cache_cluster_size
	stage.Variables = self.variables
	stage.MethodSettings = self.method_settings
	stage.AccessLogSetting = self.access_log_setting
	stage.CanarySetting = self.canary_setting
	stage.TracingEnabled = self.tracing_enabled
	if swagger is not None:
	deployment.make_auto_deployable(
	stage,
	self.remove_extra_stage,
	swagger,
	self.domain,
	redeploy_restapi_parameters,
	self.always_deploy,
	)

It appears changing any number of stage properties could cause CFN to UpdateStage and reset the Active deploymentId if new changes are not detected via the current auto_deployable hash.

Is there any reason not to use the property values of the stage parameter passed into make_auto_deployable as hash input to create a new deployment when stage properties change?

In my case, it was an isolated change to the Stage variables that caused the UpdateStage without a new deployment.