fix: publish new Lambda version when AutoPublishAliasAllProperties references a changed parameter

[roger-zhangg]

Issue #, if available

Fixes #3820

Description of changes

With AutoPublishAliasAllProperties: true, a property whose value comes from a template parameter — e.g. an Environment variable set to !Ref SomeParam — did not trigger a new Lambda version when the parameter value changed, so sam deploy published nothing.

The version's logical id is a hash of the properties that should trigger a new version. The non-AllProperties (CodeUri) path resolves parameter references before hashing, with a comment explaining exactly why — an unresolved {"Ref": "SomeParam"} hashes identically regardless of the value supplied:

code_dict = intrinsics_resolver.resolve_parameter_refs(code_dict)

The AllProperties path skipped that step and hashed the raw resource dict, so {"Ref": "TestParameter"} produced the same id whether the override was 2 or 3, and no new AWS::Lambda::Version was created.

This change resolves template parameter references on the AllProperties dict too. Pseudo parameters (AWS::Region, AWS::Partition, ...) are deliberately excluded: they live in the resolver's parameter map but do not represent a template change, and resolving them would rewrite Fn::Sub strings that reference them — shifting the version id of existing, unchanged templates. Excluding them keeps this a no-op for any template that does not reference a real parameter in a version-tracked property, so existing version ids are preserved.

⚠️ Potential breaking change — one new Lambda version on first deploy after upgrade

Flagging this explicitly: for affected templates, a customer who changes nothing in their template will get one new Lambda version published on their next deploy.

The version logical id is a hash of the tracked properties. This change alters the hash input for exactly one case, so the id shifts once even with an unchanged template:

Template shape (AutoPublishAliasAllProperties: true)	Before	After	Changes?
Property references a template parameter (!Ref MyParam)	FVersion63442c9615	FVersioncf1b5d3b18	Yes
Literal values only	FVersiona6597ab2da	FVersiona6597ab2da	No
Fn::Sub with pseudo params (${AWS::Partition})	FVersionb48d397249	FVersionb48d397249	No
!Ref to another resource (not a parameter)	FVersion7e8c27dae7	FVersion7e8c27dae7	No

(Measured by transforming the same template with the same parameter values on develop vs this branch.)

Scope: only templates that both set AutoPublishAliasAllProperties: true and reference a template parameter in a version-tracked property. Everything else is byte-identical, which is why all 2174 existing transform tests pass with no golden-file changes.

Impact of that one-time shift: CloudFormation sees a new AWS::Lambda::Version logical id, creates the new version, and points the alias at it. The old version is retained (DeletionPolicy: Retain), so nothing is deleted. Practical effects to be aware of:

• One extra version per affected function, once. Lambda's per-region code storage quota counts retained versions, so customers near that limit should know.
• If the alias is under a DeploymentPreference (canary/linear), that deploy will run a real traffic shift rather than a no-op.
• After that single deploy, ids are stable again for unchanged templates.

This is unavoidable if the bug is to be fixed at all: publishing a version when the parameter changes requires the parameter value to be part of the hash. I kept the blast radius as small as I could by excluding pseudo parameters — resolving those too would have shifted ids for any template using ${AWS::Partition}-style Fn::Sub, which is a far larger population and is what an earlier iteration of this patch did (caught by function_with_alias_and_all_properties_property).

Worth a note in the release notes.

Description of how you validated changes

• New regression tests (tests/translator/test_function_resources.py): assert that changing a referenced parameter value yields a different version logical id, and that an unchanged value is stable. Confirmed both fail against the pre-fix code and pass with the fix.
• Full tests/translator suite passes (2229 tests) with no golden-file version id changes — confirming backward compatibility. This specifically includes function_with_alias_and_all_properties_property, a fixture that uses Fn::Sub with ${AWS::Partition} etc., which a naive fix (resolving all parameters including pseudo) regressed. The pseudo-parameter exclusion is what keeps that fixture stable.
• ruff and black clean on both files.

Checklist

• Review the generative AI contribution guidelines
• Adheres to the development guidelines
• Add/update transform tests
  • Using correct values
  • Using wrong values
• Add/update integration tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[aws-sam-tooling-bot]

Code Review Results

Reviewed: f65ff54..f4f081b
Files: 2
Comments: 1

[valerena]

An Alternative to avoid the breaking change is to add a new parameter to track this behavior. Which could be something like AutoPublishAliasIncludeParameters or similar. It might be more annoying to use, but it should avoid changing the behavior in case someone even relies on this existing behavior.