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 UseOverdue.com. Also @ KnownDecimal.com
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 UseOverdue.com. Also @ KnownDecimal.com
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 UseOverdue.com. Also @ KnownDecimal.com
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.