serverless / serverless/serverless
NotificationConfiguration Error "Unable to validate the following destination configurations"
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 46.9k
- Forks
- 5.7k
- Avg merge
- 10h 7m
- Merged PRs (30d)
- 57
Description
Are you certain it's a bug?
- Yes, it looks like a bug
Is the issue caused by a plugin?
- It is not a plugin issue
Are you using the latest v3 release?
- Yes, I'm using the latest v3 release
Is there an existing issue for this?
- I have searched existing issues, it hasn't been reported yet
Issue description
I am planning to to this: S3->SNS->SQS->Lambda.
if I remove the NotificationConfiguration it works fine.
But if I include this line it gets an error.
NotificationConfiguration:
TopicConfigurations:
- Event: s3:ObjectCreated:Put
Topic: !Ref ReycAppSNSTopic1
I have seen many project use the same implementation as this one.
serverless.common.yml
custom:
stage: ${opt:stage, self:provider.stage}
resourcesRegion: ap-southeast-1
projectName: reycoapp
resourcesStages:
dev: dev
uat: uat
prod: prod
resourcesStage: ${self:custom.resourcesStages.${self:custom.common.stage}, self:custom.common.resourcesStages.dev}
memSize:
dev: 128
uat: 128
prod: 256
artifactBucket: ${self:custom.common.projectName}-${self:custom.common.stage}-deploy-layers
lambdaPolicyXRay:
Effect: Allow
Action:
- xray:PutTraceSegments
- xray:PutTelemetryRecords
Resource: "*"
Service configuration (serverless.yml) content
app: bgprocess
service: bgprocess
frameworkVersion: '3'
# Provider
provider:
name: aws
runtime: nodejs18.x
region: ${self:custom.common.resourcesRegion}
stage: dev
logRetentionInDays: 7
lambdaHashingVersion: 20201221
versionFunctions: false
memorySize: ${self:custom.common.memSize.${self:custom.common.stage}}
# Custom Variables
custom:
common: ${file(../../../serverless.common.yml):custom}
# RESOURCES
resources:
Resources:
############################### S3 Bucket ###############################
ReycAppS3Bucket:
Type: AWS::S3::Bucket
DependsOn:
- ReycAppS3SNSTopicPolicy
Properties:
BucketName: ${self:service}-${self:custom.common.stage}-u1
# S3 to SNS Configuration
NotificationConfiguration:
TopicConfigurations:
- Event: s3:ObjectCreated:Put
Topic: !Ref ReycAppSNSTopic1
# Bucket 2
ReycAppS3Bucket2:
Type: AWS::S3::Bucket
Properties:
BucketName: ${self:service}-${self:custom.common.stage}-u2
############################### SNS Topics ###############################
ReycAppSNSTopic1:
Type: AWS::SNS::Topic
# DependsOn - makes sure that the dependencies are create or updated first
DependsOn:
- ReycAppSQSQueue1
Properties:
TopicName: ${self:service}-${self:custom.common.stage}-tp1
# List of sqs subscribed to this sns
Subscription:
- Endpoint:
Fn::GetAtt:
- ReycAppSQSQueue1
- Arn
Protocol: sqs
# SNS Policy - S3 Triggered
ReycAppS3SNSTopicPolicy:
Type: AWS::SNS::TopicPolicy
Properties:
Topics:
- !Ref ReycAppSNSTopic1
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
- sns.amazonaws.com
Action:
- "sns:Publish"
Resource: !Ref ReycAppSNSTopic1
Condition:
# Here we are using hardcoded arn
ArnLike:
aws:SourceArn: arn:aws:s3:::${self:service}-${self:custom.common.stage}-u1
############################### SQS Queues ###############################
# SQS Queues
ReycAppSQSQueue1:
Type: AWS::SQS::Queue
Properties:
QueueName: ${self:service}-${self:custom.common.stage}-q1
# SQS Policy
ReycAppSQSQueuePolicy:
Type: AWS::SQS::QueuePolicy
# DependsOn - makes sure that the dependencies are create or updated first
DependsOn:
- ReycAppSQSQueue1
Properties:
Queues:
- Ref: ReycAppSQSQueue1
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
- "events.amazonaws.com"
- "sqs.amazonaws.com"
- "sns.amazonaws.com"
Action:
- "sns:Publish"
- "sqs:SendMessage"
- "sqs:ReceiveMessage"
Resource:
Fn::GetAtt:
- ReycAppSQSQueue1
- Arn
Condition:
ArnEquals:
aws:SourceArn:
Ref: ReycAppSNSTopic1
############################### Outputs ###############################
Outputs:
# S3 Outputs
ReycAppS3BucketName:
Value: !Ref ReycAppS3Bucket
Export:
Name: ${self:service}-${self:custom.common.stage}-u1
ReycAppS3BucketNameArn:
Value:
Fn::GetAtt:
- ReycAppS3Bucket
- Arn
Export:
Name: ${self:service}-${self:custom.common.stage}-u1arn
ReycAppS3BucketName2:
Value: !Ref ReycAppS3Bucket2
Export:
Name: ${self:service}-${self:custom.common.stage}-u2
ReycAppS3BucketName2Arn:
Value:
Fn::GetAtt:
- ReycAppS3Bucket2
- Arn
Export:
Name: ${self:service}-${self:custom.common.stage}-u2arn
# SNS Outputs
ReycAppSNSTopic1:
Value: !Ref ReycAppSNSTopic1
Export:
Name: ${self:service}-${self:custom.common.stage}-tp1
# SQS Outputs
ReycAppSQSQueue1Arn:
Value:
Fn::GetAtt:
- ReycAppSQSQueue1
- Arn
Export:
Name: ${self:service}-${self:custom.common.stage}-q1
Command name and used flags
sls deploy -s dev
Command output
sls deploy -s dev
× Stack bgprocess-dev failed to deploy (36s)
Environment: win32, node 20.10.0, framework 3.38.0, plugin 7.2.0, SDK 4.5.1
Credentials: Local, "default" profile
Docs: docs.serverless.com
Support: forum.serverless.com
Bugs: github.com/serverless/serverless/issues
Error:
CREATE_FAILED: ReycAppS3Bucket (AWS::S3::Bucket)
Resource handler returned message: "Unable to validate the following destination configurations (Service: S3, Status Code: 400, Request ID: 914GC0BE7HNT5Y94, Extended Request ID: LMTlVDA1hdcSWbkzWLT6kc7Lhl/zOST39q1GuyArVEHtWtS7pLkp52m+O+Wt7CZX0U7StPxZMsA=)" (RequestToken: b90a9257-3625-d5cd-4db1-85473dd47eb5, HandlerErrorCode: InvalidRequest)
Environment information
Framework Core: 3.38.0
Plugin: 7.2.0
SDK: 4.5.1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The reproduction is in serverless.yml and serverless.common.yml; start by running sls deploy -s dev with the listed Serverless, Node.js, and AWS versions. Check the S3 TopicConfigurations against the SNS topic and its policies, then determine whether the framework needs a change or clearer validation. Done means a reproducible diagnosis and a regression test or documented configuration fix.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, javascript, node.js
- Domain
- backend, cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 22/100