Motivation:
- A active record rollback could occur while enqueuing a job in this
case the job would enqueue even though the database deletion
rolledback putting things in a funky state. So this adds some
functionality to ensure that deletions are not queued until after
the db transaction has been commited.
Related Issues:
- Sort of related to https://github.com/rails/rails/issues/26045
Changes:
- add some syntatic sugar to transactions to make enqueueing a job a
little better experience, this really hooks into the after destroy
hook on the transaction.
- Setup async destroy on associations to not enqueue until after a
transaction has been committed.
Sometimes cascading association deletions can cause timeouts due to
an IO issue. Perhaps a model has associations that are destroyed on
deletion which in turn trigger other deletions and this can continue
down a complex tree. Along this tree you may also hit other IO
operations. Such deep deletions can lead to server timeouts while
awaiting completion and really the user may not notice all the
changes on their side immediately making them wait unnecesarially or
worse causing a timeout during the operation.
We now allow associations supporting the `dependent:` key to take `:destroy_async`,
which schedules a background job to destroy associations.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
Co-authored-by: Cory Gwin @gwincr11 <gwincr11@github.com>
