This is awesome 👍

But just curious: why not usedependent: :destroy_later?

That seems more consistent with other delayed methods:purge_later,deliver_later,perform_later, etc.

Is there something about the behavior that makes:destroy_async more appropriate than:destroy_later?

@rafaelfranca@adrianna-chang-shopify I don't want to be a pest 😅 but I think it would be useful for the community to understand why this option is named:destroy_async vs:destroy_later as mentionedhere. If there's something about this behavior that makes it different from the rest of the*_later functionality built into Rails, it would be useful to know why it's different. 💕

The reason for the different name if because we wanted to keep thedestroy_later namefor the class level feature that we wanted to introduce. In that feature, we cared when exactly the destroy happened.

For the feature implemented here we don't care if the destroy happen in 1s or in 10 minutes. It just need to happen async, without blocking the current request.

So the behavior ofdependent: :destroy_async is similar to_later methods, the only difference is that you can't configure when it will happen. That, and we wanting to keep the concept different from thedestroy_later class level feature, was enough to not use the_later suffix.

Would a PR to adddependent: :delete_async be beneficial to others? We have some cases where we would prefer to usedelete rather thandestroy.

@tomrossi7 👍 on:delete_async for me, I do have a case where I would need this (don't need the slower:destroy because there's no callbacks or dependencies, yet:delete is still too slow to do synchronously due to database fragmentation)

And also thanks for this:destroy_async feature in Rails, it's a great addition 🎉