Skip to content

fix(notifications): merge SNS/SQS policies for shared topics and queues (#275)#747

Merged
zirkelc merged 1 commit intomasterfrom
fix-275-notifications-policy-merge
Apr 4, 2026
Merged

fix(notifications): merge SNS/SQS policies for shared topics and queues (#275)#747
zirkelc merged 1 commit intomasterfrom
fix-275-notifications-policy-merge

Conversation

@VirtueMe
Copy link
Copy Markdown
Collaborator

@VirtueMe VirtueMe commented Apr 2, 2026

Summary

Fixes issue #275: when multiple state machines send notifications to the same SNS topic or SQS queue (fan-in), the plugin generates a separate AWS::SNS::TopicPolicy / AWS::SQS::QueuePolicy resource per state machine. AWS::SNS::TopicPolicy and AWS::SQS::QueuePolicy are full replacements in CloudFormation — when two resources target the same topic/queue, the second overwrites the first. The first machine's notification rules then silently stop working because their principal is no longer in the policy.

Fix

After compiling all notification resources, same-target SNS topic policies and SQS queue policies are merged into a single CloudFormation resource with all statements combined. CloudFormation then applies the policy exactly once with all principals authorised.

The change is in compileNotifications.js: a mergeResourcePolicies step groups AWS::SNS::TopicPolicy resources by topic and AWS::SQS::QueuePolicy resources by queue, merging statements before the resources are written into the CloudFormation template.

Verification

Integration test: The notifications fixture was updated to include a second state machine (notificationMachine2) sharing the same SNS topic and SQS queue as the first — the exact fan-in scenario from #275.

The compiled CloudFormation template was inspected after packaging with the fix applied:

SNS TopicPolicy resources: 1
  IntegrationDashnotificationsDashtestResourcePolicyc30a6: 2 statement(s)

SQS QueuePolicy resources: 1
  IntegrationDashnotificationsDashtestResourcePolicy6fbc7: 2 statement(s)

One merged policy per target, with one statement per state machine. Without the fix, two separate resources would be generated for each target, causing CloudFormation to overwrite the first machine's policy with the second's. LocalStack deploy is green.

Unit tests: Three new tests added covering:

  • Two state machines sharing the same SNS topic → 1 policy, 10 merged statements
  • Two state machines sharing the same SQS queue → 1 policy, 10 merged statements
  • One state machine with the same topic on multiple statuses → 1 policy, 2 merged statements

Test plan

  • npm test — 533 passing
  • npx osls notifications:deploy --stage test — green
  • Packaged template confirms 1 merged AWS::SNS::TopicPolicy and 1 merged AWS::SQS::QueuePolicy with statements from both state machines

Closes #275

🤖 Generated with Claude Code

@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new bot commented Apr 2, 2026

Open in StackBlitz

npm i https://pkg.pr.new/serverless-operations/serverless-step-functions@747

commit: fe678cd

@VirtueMe
Copy link
Copy Markdown
Collaborator Author

VirtueMe commented Apr 2, 2026

Note: the manual template inspection used to verify this fix (#275) revealed a gap in the integration test suite — LocalStack deploys green for this class of bug but the incorrect template is only visible by inspecting the compiled output. Tracked in #748.

AWS::SNS::TopicPolicy and AWS::SQS::QueuePolicy are full replacements:
when two separate CloudFormation resources target the same topic/queue,
the second overwrites the first. When multiple state machines share a
notification topic or queue (fan-in), the second machine's policy
destroys the first machine's permissions — its notification rules stop
working silently.

Fix: after compiling all notification resources, group SNS topic
policies by topic and SQS queue policies by queue. Same-target policies
are merged into a single resource with all statements combined, so
CloudFormation sets the policy exactly once with all principals
authorised.

Adds three unit tests covering:
- Two state machines sharing the same SNS topic
- Two state machines sharing the same SQS queue
- One state machine with the same topic on multiple statuses

Updates the notifications integration fixture to include a second state
machine sharing the same SNS topic and SQS queue as the first, matching
the fan-in scenario described in #275.

Adds fixtures/notifications/verify.test.js as the first implementation
of the post-deploy template assertion pattern tracked in #748. It reads
the compiled CloudFormation template after deployment and asserts
exactly one SNS/SQS policy per unique target with statements from all
state machines, catching silent policy-overwrite regressions that a
successful deploy alone cannot detect.

Closes #275

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@VirtueMe VirtueMe force-pushed the fix-275-notifications-policy-merge branch from aa959d4 to fe678cd Compare April 2, 2026 08:37
@zirkelc zirkelc merged commit 6444f28 into master Apr 4, 2026
4 checks passed
@zirkelc zirkelc deleted the fix-275-notifications-policy-merge branch April 4, 2026 04:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Using notifications overwrites exisiting resouce permissions.

2 participants