Destroy does not trigger after_commit :destroy

[cfeckardt]

CONTEXT
When adding acts_as_paranoid to existing classes that utilise after_commit blocks, paranoia unexpectedly does not handle destruction of records properly.

STEPS TO REPRODUCE
With a class Foo, that acts_as paranoid,
The following snippet is not called:

after_commit on: :destroy do
  # ...
end

When this snippet is run:

f = Foo.new
f.destroy!

EXPECTATION
I expected the after_commit callback to be called.

ACTUAL OUTCOME
The after_commit callback was never called.

MORE INFO
Relates to #296

One work around is to check after_commit on: :update, if the deleted_at column is set or not, but it's not an ideal soluton.

Is the current behaviour the desired behaviour?
If not, I'd be happy to contribute a fix.

[mustela]

This is still happening, and with Rails 5.1 the approach of checking for the deleted_at column, doesn't work any more. Has anyone found another workaround to this?

[mustela]

This actually works (solution from vital) after_commit if: -> { deleted_at.present? && attribute_before_last_save(:deleted_at).blank? }

[koenpunt]

I'm currently in the process of upgrading a Rails 4.2 project to 5.1, and in 4.2 the after_commit hook was working fine, but in 5.1 it is not.

[k-rudy]

guys any updates on this issue? for us it's a very important one

[cfeckardt]

@jhawthorn what is the desired behaviour here?

[lisbethw1130]

hmm.... it seems that this issue is still happening Rails 6.0.0.beta3

[bubbaspaarx]

still happening. Works on create and update but not on destroy. this has been happening for while it seems... any chance of a workaround?

[rapito]

If anyone needs a workaround after_destroy works perfectly.
@mustela @bubbaspaarx

[donv]

@rapito but after_destroy is called before commit, right?

[prdanelli]

Rails 6.0.2, after_commit :foo, on: :destroy fails to trigger the callback correctly.

As this was first reported in 2016, should I assume its now a feature?