serverless - dynamo streams - how to setup destinationConfig? - aws-lambda

Question

i have the following lambda configuration:
MyFunc:
handler: my_handler
timeout: 60
role: myrole
events:
- stream:
type: dynamodb
arn: <<dynamo_db_stream_arn>
startingPosition: LATEST
maximumRetryAttempts: 3
destinations:
onFailure: <sqs_queue_arn>
enabled: True
Yet, when deploying, i don't see that the onFailure is even rendered in the cloudformation template.
i've set it up as said in this documentation:
https://serverless.com/framework/docs/providers/aws/events/streams/
Any idea what i'm missing?
==========================
So, completing Snickers3192's answer - I actually am not sure what's wrong with the configuration above, as serverless should support it, but eventually what i did is created the stream handler in another resource, so basically my serverless looks like that:
functions:
MyFunc:
handler: my_handler
timeout: 60
role: myrole
resources:
Resources:
MySourceMapping:
Type: AWS::Lambda::EventSourceMapping
DependsOn: MyFuncLambdaFunction
Properties:
EventSourceArn: <dynamo_db_stream_arn>
FunctionName: MyFunc
MaximumRetryAttempts: 3
StartingPosition: LATEST
DestinationConfig:
OnFailure:
Destination: <sqs_queue_qrn>

Answer 1

I think you're just missing "arn:"
Here's what worked for us.
maximumRetryAttempts: 10
maximumRecordAgeInSeconds: 300
bisectBatchOnFunctionError: true
destinations:
onFailure:
arn:
Fn::GetAtt:
- fileReducerDeadLetterQueue
- Arn
type: sqs

Answer 2

Even though I like serverless framework, I don't recommend using it for anything other than developing Lambda functions, I wouldn't even use the http event for creating an API gateway. Stick to the unix philosophy do one thing good, that's how I feel serverless should stick to that, not try and become another terraform or something, it isn't.
So create your Lambda functions in serverless and that's it. Do the other stuff else where. If the resource can be managed effectively in Cloudformation AWS::Lambda::EventSourceMapping, then you can use that. If it makes sense to put it at the bottom of the serverless.yml in resources: you can do that, but if not then let it have it's own template.
There is quite a number of permissions needed for setting up your lambda for DynamoDB streams, I wouldn't trust serverless to do that for you. A proper AWS prod setup as well might not let some external tool create iam roles as well.
As soon as you differ the slightest little bit from the serverless default cloudformation template, you'll have problems, probably you are spending hours right now, on a tool which was supposed to save you time, therefore defeating it's purpose. I suggest making more stacks than less, and using conventions when one stack needs a Lambda in another, this is actually more manegable as when one thing fails you can still update other stacks, and swap stacks as you change, you can't do that if you stick it all in a serverless.yml.