Adds FilterPolicy to SNS event

[laardee]

What did you implement:

Closes #5221

How did you implement it:

Inline subscription for the topic doesn't support filter policy, so I changed the subscription to be separate resource.

This increases the resource count in the template, so it can be an issue if someone has a stack which is hitting the limits and updates the a new version.

Option would be to write separate subscription resource only when filter policy exists.

How can we verify it:

Example setup for creation a subscription with a filter policy

functions:
  pets:
    handler: pets.handler
    events:
      - sns:
          topicName: pets
          filterPolicy:
            pet:
              - dog
              - cat

Todos:

• Write tests
• Write documentation
• Fix linting errors
• Make sure code coverage hasn't dropped
• Provide verification config / commands / resources
• Enable "Allow edits from maintainers" for this PR
• Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

[eahefnawy]

@laardee thanks for this change! Yeah the resource limit is a common issue and we should stick to a minimum.

Option would be to write separate subscription resource only when filter policy exists.

Yes, let's do that. I'd hate to add unnecessary resources for basic SNS users just to support FilterPolicy, even if they don't use it.

[laardee]

@eahefnawy There were already so many conditions that I thought that it would be even more complex if the separate subscription is created only when filter policy exists, but I think it turned out quite ok.

[horike37]

Thank you for adding this feature @laardee
LGTM 👍 and also like the solution which resources keep minimum 💯

Maybe he is also approval

[esbenvb]

Is it a normal procedure that the documentation gets updated before the features are released? I was really happy to see that this feature is now supported in serverless (good job, BTW), but now feel that I've "wasted" some time on migrating the filter policy configuration from my old cli script to my serverless.yml - only to find out that the documentation does not reflect the latest stable release.

https://serverless.com/framework/docs/providers/aws/events/sns/

[JVUnderground]

@esbenvb
Same exact thing happening to me today as well. Sign that this shouldn't be normal procedure.

[laardee]

@esbenvb @JVUnderground you are correct, it is very misleading that docs are updated before release (what in a worst case takes weeks). I guess the docs are updated once the PR is merged to the master branch. gitflow or similar could be an option. Then the docs would be updated when the new version is released.

If you already haven't, you could open a new issue considering this.

[ricardovf]

@laardee Thanks for this. Can i have two filter policies? Trying it but cant get to work...

snsChat:
    handler: src/main.handlerChat
    events:
      - sns:
          arn: !Ref SnsTopic
          topicName: ${self:custom.snsTopic}
          filterPolicy:
            action:
              - connection_opened
              - message_received
            scope: chat

on node:

this.sns
      .publish({
        Message: JSON.stringify(message),
        MessageAttributes: {
          scope: {
            DataType: 'String',
            StringValue: scope,
          },
          action: {
            DataType: 'String',
            StringValue: `${action}`,
          },
        },
        TopicArn: this.snsTopicArn,
      })

output:

pushpin-test-dev-snsChat","Owner":"","Attributes":{"FilterPolicy":"[{\"action\":[\"connection_opened\",\"message_received\"]},{\"scope\":\"chat\"}]"},"Policies":[{"action":["connection_opened","message_received"]},{"scope":"chat"}]}]
Serverless: DEBUG[serverless-offline-sns][server]: filterPolicy Failed: [{"action":["connection_opened","message_received"]},{"scope":"chat"}] did not match message attrs: {"scope":{"Type":"String","Value":"chat"},"action":{"Type":"String","Value":"connection_opened"}}
Serverless: DEBUG[serverless-offline-sns][server]: Filter policies failed. Skipping subscription: http://127.0.0.1:4002/lambda-test-dev-snsChat

[ricardovf]

Found the problem. Scope also needs to be an array.

Thanks!

snsChat:
    handler: src/main.handlerChat
    events:
      - sns:
          arn: !Ref SnsTopic
          topicName: ${self:custom.snsTopic}
          filterPolicy:
            action:
              - connection_opened
              - message_received
            scope:
              - chat