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.

[roger-zhangg]

Sorry for the slow reply, @valerena — and thanks, the breaking-change framing is the right question to ask.

My argument for keeping this as a fix rather than a new property:

1. The current behaviour contradicts the documented contract. AutoPublishAliasAllProperties exists to publish a new version when any function property changes. A property whose value came from !Ref SomeParameter changing is a property change. The non-AllProperties path already resolves parameter refs before hashing, with an explicit comment saying exactly why:

When using intrinsic functions there are two cases when hash must change:

• Value of the template parameter changes
• (or) LogicalId of a referenced resource changes

So this isn't introducing new semantics, it is making AllProperties agree with the path next to it.

2. The failure mode of today's behaviour is silent and bad. You change --parameter-overrides, the deploy succeeds, and the alias keeps pointing at a version built from the old parameter value. There is no error and no warning. For something like a changed env var or a feature flag, users get a stale alias and no signal. Anyone "relying" on the current behaviour is relying on versions silently not tracking their config.

3. A new opt-in property makes the common case the hard case. AutoPublishAliasIncludeParameters would be a flag essentially everyone using AllProperties should set, which is a strong hint it should be the default rather than an opt-in — and it permanently adds surface area we'd have to keep supporting.

Scope of the change, concretely: it only affects templates that set AutoPublishAliasAllProperties: true and reference template parameters in function properties. For those, the change is "a new version gets published where previously none did" — extra versions, never a missing one, and never a different alias target than the template asks for.

On the second commit (49f76536): that addresses your earlier review point and is worth calling out separately, because the first attempt had a real bug. resolve_parameter_refs mutates the dict it is handed, and the values reachable from _generate_resource_dict() are the live objects from the user's template (properties["Environment"] is function.Environment). Resolving in place inlined parameter values into the resources the translator actually emits — I confirmed a NoEcho parameter value appearing in the emitted AWS::Lambda::Function. It now resolves against a copy, with a regression test.

That said, this is your repo's compatibility bar, not mine — if you'd still rather have the opt-in property, say so and I'll rework it that way. I'd just like the decision recorded here so it doesn't sit for another month. Happy to take it to a quick sync if that's faster.