Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for fanout pattern (multiple subscriptions) #521

Open
lsacco-nutreense opened this issue Mar 13, 2022 · 1 comment
Open

Support for fanout pattern (multiple subscriptions) #521

lsacco-nutreense opened this issue Mar 13, 2022 · 1 comment

Comments

@lsacco-nutreense
Copy link

I find that this plugin works well for 1:1 message transfer between sns and sqs, but do you support sqs with multiple subscriptions. My use case requires the use of the SNS fanout pattern, so I'm wondering what the configuration would look like. I tried the most obvious config below, but I only see one (the last) subscription bound to my SQS queue.

functions:
  processEvent:
    handler: handler.backofficeConsumer
    events:
      - snsSqs:
          name: sqsbackoffice
          topicArn: !Ref RegisterBroker
      - snsSqs:
          name: sqsbackoffice
          topicArn: !Ref UpdateBroker

resources:
  Resources:
    RegisterBroker:
      Type: AWS::SNS::Topic
      Properties:
        TopicName: sns-register-broker
    UpdateBroker:
      Type: AWS::SNS::Topic
      Properties:
        TopicName: sns-update-broker

In serverless.yml I could do something like this, but I want to use your integration to have a queue between them:

functions:
  hello:
    handler: handler.run
    events:
      - sns:
          arn: arn:aws:sns:us-east-1:00000000000:topicname
          topicName: topicname-account-1-us-east-1
      - sns:
          arn: arn:aws:sns:us-east-1:11111111111:topicname
          topicName: topicname-account-2-us-east-1

Appreciate any suggestions.

@NoxHarmonium
Copy link
Collaborator

Hi @lsacco-nutreense, thanks for the report!

I think this isn't working because the CloudFormation logical IDs are generated based on the name attribute, so your two snsSqs definitions are conflicting with each other. In fact, I think after #552 lands, you would get an error instead of a silent failure. It seems somewhat related to #444

I'll do some testing at some point,. In the meantime, you might be able to get it to work by giving each event definition a different name attribute. For example:

functions:
  processEvent:
    handler: handler.backofficeConsumer
    events:
      - snsSqs:
          name: sqsbackoffice1
          topicArn: !Ref RegisterBroker
      - snsSqs:
          name: sqsbackoffice2
          topicArn: !Ref UpdateBroker

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

No branches or pull requests

2 participants