Repository navigation
chore(cfn): CUDly-CrossAccount PrimaryRoleName still defaults to the retired stack's role #1585
Description
#1577 retired the CloudFormation install stack (D29). cloudformation/stacks/CUDly-CrossAccount is a target-account role template and stays. Its PrimaryRoleName parameter still defaults to CUDly-LambdaRole, the role the retired stack created. Terraform installs name the runtime role differently.
Owner decision: changing the default affects anyone who deploys the template without overriding it. Options:
- make it required, with no default;
- default it to the Terraform Lambda role's name;
- leave it and document it.
Found in review of #1577.
Activity
cristim commentedon Nov 5, 2026
Triaged: p3, waiting on the owner's choice among the three options above (no default, default to the Terraform role name, or document it). The change itself is one line.
cristim commentedon Nov 12, 2026
Owner go (2026-11-12, decide-now list): claude-platform-2 is implementing this item now per the recorded decision; if another lane holds an uncommitted claim on it, please hand over via the bus instead of duplicating.
cristim commentedon Nov 12, 2026
Decided (owner go 2026-11-12) by claude-platform-2 and landed 447a98b on main (two review passes, local verify: cfn-lint, go test ./internal/iacfiles, terraform fmt -check and validate on the lambda module and environments/aws without credentials; CI green on the commit: CI - Build & Test, pre-commit, frontend-build-sentinel, Deploy to AWS Lambda). The owner decision was to default PrimaryRoleName to the current Lambda role. No fixed default can be right: the Terraform runtime role is created with name_prefix '<stack_name>-lambda-' (stack_name = --) and AWS appends another random suffix, and IAM trust principals cannot take wildcards; nothing deploys CUDly-CrossAccount programmatically, so no caller can pass the value either. So the parameter now has no default (the issue's option 1) and is validated as a bare IAM role name (1-64 characters, no path or ARN), and the value comes from a new lambda_role_name Terraform output (null on Fargate; name_prefix is unchanged so the role is not replaced). Existing stacks must pass their current value explicitly on update (UsePreviousValue=true): an omitted parameter now fails instead of silently re-pointing the trust policy; Terraform-install stacks that kept the old default already have a dead trust policy and should set the real name. CHANGELOG (Unreleased notices) and docs/DEPLOYMENT.md say so, and a test asserts there is no default and checks the pattern. This departs from the literal wording 'default to the current Lambda role'; the owner can override by choosing a naming scheme (for example an explicit fixed role name in Terraform, which would replace the role on existing installs).