How do I tell what trigger async vs sync? Im using Event Scheduler to invoke a function. If that function fails, I want to send the onFailure to a different Lambda. Im having trouble getting it working, but I wonder if its because of the async trigger vs sync trigger issue you spoke about.
David could you do a video on Former2? It's a tool which builds a CloudFormation template from manually created resources, similar to the deprecated CloudFormer
Do we really need lambda destinations most of the time? What if I just add a try catch into the code and make it send succeeded events into the successSQS queue and vice versa when it fails and lands in the catch statement. Would that not be the same thing as implementing lambda destinations in this case?
You could certainly do this - however consider the scenario if your call to send the message into SQS fails, what then? You'll have to add some messy failure handling logic to handle this scenario. Using destinations, Lambda handles the delivery for you.
@@maxmaximus7773 in addition to what was said by @BeABetterDev doing this alone can slightly increase the execution time of your function and consequently increase your bills
![[Watch Party] RoV Pro League 2024 Winter | with Moowan ( Bacon Time Vs Talon )](http://i.ytimg.com/vi/CCEDhu6dPN8/mqdefault.jpg)
You're an excellent educator! Thank you!
This is very helpful! It fixed my problem. Thanks!
Glad it helped!
Excellent video man!! Great channel!
How do I tell what trigger async vs sync?
Im using Event Scheduler to invoke a function. If that function fails, I want to send the onFailure to a different Lambda.
Im having trouble getting it working, but I wonder if its because of the async trigger vs sync trigger issue you spoke about.
Thank you!
Good little bonus feature. I'm guessing most people will use only a failure queue because success is expected.
Agree - I don’t see usecase for success queue for now - probably happy path should be in code :)
Love your channel 👍
Thank you Daniel, your TH-cam channel is great!
Thank you so much!!
David could you do a video on Former2? It's a tool which builds a CloudFormation template from manually created resources, similar to the deprecated CloudFormer
Great thanks
Thanks man
Failure Q = DLQ?
Do we really need lambda destinations most of the time?
What if I just add a try catch into the code and make it send succeeded events into the successSQS queue and vice versa when it fails and lands in the catch statement.
Would that not be the same thing as implementing lambda destinations in this case?
You could certainly do this - however consider the scenario if your call to send the message into SQS fails, what then? You'll have to add some messy failure handling logic to handle this scenario. Using destinations, Lambda handles the delivery for you.
@@BeABetterDev makes sense. Thank you for the reply
@@maxmaximus7773 in addition to what was said by @BeABetterDev doing this alone can slightly increase the execution time of your function and consequently increase your bills