Conversation
…olicy names The env-specific policy-name suffix read `getEnvInfo().envName` directly. When env info is absent or blank (uninitialized env / headless / export paths) the suffix silently became `..._undefined`, which puts every such deployment back on one shared policy name and re-collides -- the exact bug this change fixes -- or threw an opaque error on a path that previously succeeded. Read the env name once and validate it: fail fast with a clear `EnvironmentNotInitializedError` when it is missing or empty, so names never degrade to a shared `_undefined` suffix. Adds a regression test covering the missing-envName case alongside the existing happy-path test.
sarayev
reviewed
Aug 24, 2026
…orted auth
Appending the environment name to every S3 IAM policy name renamed the inline
policy for all already-deployed storage apps. PolicyName is replace-on-update for
AWS::IAM::Policy, so the next push after upgrading would force a policy
replacement on every existing environment -- churn and risk well beyond the
shared-role collision this fixes, and it hit apps that never had the problem.
The collision only occurs when the auth/unauth IAM roles are shared across
environments, which is the imported Cognito Identity Pool case. Gate the
`_${envName}` suffix on imported auth (detected from project meta): managed-auth
apps keep the legacy env-agnostic name and see no policy replacement on upgrade,
while imported-auth environments -- whose deploys are already failing -- get the
unique per-env name. The missing-envName fail-fast now applies only on the
imported path.
Adds a regression test asserting managed auth keeps the legacy names, alongside
the imported happy-path and imported missing-envName tests.
sarayev
reviewed
Aug 24, 2026
sarayev
left a comment
sarayev
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the quick turnaround, both of my concerns are addressed nicely.
Gating the suffix on imported auth is exactly the backward-compatible shape I was hoping for: managed-auth apps keep the legacy name and see no policy replacement on upgrade, and only the shared-role environments (whose deploys are already failing) get the env-scoped name. Scoping the fail-fast to the imported path and tracing the callers to confirm envName is always present there also resolves the export/headless worry. The three tests (imported gets the suffix, managed keeps the legacy name, imported + blank env throws) lock the behavior in well. Looks good to me.
Left one small nit inline on the $TSAny cast, non-blocking.
sharonyajain
approved these changes
Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes
I made generated S3 IAM policy names environment-specific by appending the current Amplify environment name to the existing policy UUID. This prevents two environments that share imported auth roles from trying to manage identically named inline policies.
I also added a focused regression test for the generated policy names and updated the existing stack-transform expectations.
Issue #, if available
Fixes #14961
Description of how you validated changes
yarn lerna run build --scope @aws-amplify/amplify-category-storage --include-dependencies --concurrency 4node ../../node_modules/jest/bin/jest.js --runInBand --coverage=falsefrompackages/amplify-category-storage(15 suites, 48 tests)I did not run cloud E2E tests or the macOS CI job locally.
Checklist
yarn testpasses for the changed packageBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.