I'm a husband, dad, and rails dev who builds things to help businesses from the bootstrapper on up. Helping recover your business failed payments with Overdue.io.
I'm a husband, dad, and rails dev who builds things to help businesses from the bootstrapper on up. Helping recover your business failed payments with Overdue.io.
I think you should use after_create_commit, as after_commit will get called for every update operation. If you end up updating the signup record in any situation, you might send a duplicate notification if you don't have any conditions to check whether is it a new record or not while sending notification. or use like this after_commit :do_foo_bar, on: [:create]
I'm a husband, dad, and rails dev who builds things to help businesses from the bootstrapper on up. Helping recover your business failed payments with Overdue.io.
Glad it got worked out!
Definitely! Glad it was only a few extra welcome emails to my customers and not a bunch of emails to my customers customers.
btw we ran into the same Sidekiq/
after_create
realization a little while back, luckily we switched directly toafter_create_commit
.I know what I’m doing after I’m done eating drinking this glass of orange pineapple juice! Don’t think I’ve seen after_create_commit. Thanks!
I think you should use after_create_commit, as after_commit will get called for every update operation. If you end up updating the signup record in any situation, you might send a duplicate notification if you don't have any conditions to check whether is it a new record or not while sending notification. or use like this
after_commit :do_foo_bar, on: [:create]
Thanks. Yeah after_commit was a mistake, hence the title of my article. I swapped to after_commit_create after Ben pointed it out.