after_destroy_commit callback is not triggered on soft delete

[cweyer]

According to the documentation (and also tested behaviour) acts_as_paranoid classes trigger the after_destroy callbacks whenever an object is soft-deleted and after_real_destroy when the object is really removed from the database. However there is another AR callback called "after_destroy_commit" which are not triggered on soft-delete. This caused a bug in our implementation, as I would expect it to be desired behaviour that after_destroy_commit callbacks are actually triggered on soft delete. The callback could be fired once the deleted_at-update commit has been committed to the database.

[jamescontent]

We have had to avoid the use of after_destroy_commit and after_commit :some_hook, on: :destroy altogether because of the way destroy is monkey-patched in this gem. I don't think it's the end of the world for our purposes, but it does seem problematic to not support after_commit callbacks.

[strom2357]

For what it's worth there's a pull request that purports to resolve this that's been open a while now:
#404

[dillon9693]

This appears to be fixed as part of v2.4.3. I just updated to latest version, and it's now working as expected (was previously on v2.4.2).

Looks like #482 actually fixed it

[snogrammer]

@dillon9693 @hashwin

This is still not working for me. Any advice on how you triggered the callbacks in Rails 6?

Tried with the following:

• rails 6.0.3 (and 6.1.3.1)
• paranoia 2.4.3

Neither after_commit or after_destroy get trigged when calling Object.destroy

[wchan2]

I'm also still experiencing the same thing for before_destroy with paranoia version 2.6.0 and rails 7.0.2.3.

[mathieujobin]

I'd like to know what is causing it, I haven't been able to track it down...

[wchan2]

@mathieujobin False alarm. Realized the code was calling .delete on the model and not destroy. It's working correctly now. Apologies for the confusion.