fix(notifications): dedupe SNS/SQS policy statements by Sid (#801)

[VirtueMe]

Closes #801

Summary

• mergeResourcePolicies (added in fix(notifications): merge SNS/SQS policies for shared topics and queues (#275) #747) concatenates same-target SNS/SQS policy statements, but the Sid carries no state-machine identity — it's derived from status + target type + (action, resource) only. So two state machines sharing a topic/queue emit byte-identical statements with the same Sid. AWS rejects that template: Invalid parameter: Every policy statement must have a unique ID (regression from fix(notifications): merge SNS/SQS policies for shared topics and queues (#275) #747, reported on that PR).
• Dedupe statements by Sid while merging (new mergeStatements helper). The grant is per-target, not per-machine, so keeping one statement per Sid is correct. The SNS/SQS branches are folded into one table-driven loop.
• Unit tests assert Sid uniqueness for shared SNS/SQS targets; two pre-existing count assertions (10→5) that encoded the buggy pre-dedup behaviour are corrected.
• The notifications fixture verify.test.js swaps its statement-count checks for Sid-uniqueness guards. LocalStack accepts duplicate Sids (which is how fix(notifications): merge SNS/SQS policies for shared topics and queues (#275) #747 shipped green), so only the compiled-template assertion catches this class — see test: add post-deploy template assertion suite for integration fixtures #748.

Test plan

• npm test — 618 passing
• npm run lint — clean
• Packaged notifications fixture → one merged policy per target, 1 statement with a unique Sid each

🤖 Generated with Claude Code

[pkg-pr-new]

Open in StackBlitz

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

commit: 33c7a40

[zirkelc]

A stable key might require a sort first, otherwise the keys follow insertion order.

@copilot wdyt?

[Copilot]

Good call — I updated this in 010fcd6 by normalizing the merge key with a sorted target list before JSON.stringify, so equivalent topic/queue sets produce a stable key regardless of insertion order.

[VirtueMe]

Very good call!

[zirkelc]

@copilot that still does not sort the keys, right?

here is what I meant:

function stringifyJSON(obj) {
  return JSON.stringify(obj, (key, value) =>
    value && typeof value === 'object'
      ? Object.keys(value)
          .sort()
          .reduce<{ [key: string]: unknown }>((result, k) => {
            result[k] = value[k];
            return result;
          }, {})
      : value,
  );
}

[Copilot]

You're right — I updated this in 3f21642 to canonicalize objects recursively (sorted keys) before stringifying, and then sort the target list by that canonical string.

[zirkelc]

@copilot why is better in your solution than using the the replace arg of JSON.stringify?

[Copilot]

Nothing fundamentally better—both approaches are valid. I used a separate canonicalize+stringify helper mainly for readability/reuse and explicit recursion in tests/debugging. If you prefer, I can switch to the JSON.stringify replacer form for the same behavior.

[zirkelc]

@copilot yes do that

[Copilot]

Updated in 33c7a40 to use the JSON.stringify replacer form for stable key serialization (with sorted object keys) in the policy merge key path.