Issues When Rescuing ActiveRecord::RecordNotUnique - sql

Question

I'm attempting to build a table which will act as a queue of batched syncs to a third party service.
The following method should speak for itself; but to be clear, its intention is to add a new updatable object (a polymorphic relationship) with status: :queued to the delayed_syncs table.
There is a uniqueness constraint on the polymorphic relationship + status (updatable_id, updatable_type, status) which should cause updatable objects already in the queue with the :queued status to fail here and fall into the rescue block.
The issue I am seeing is that whenever the SELECT generated by find_by is fired, this entire method fails with a:
ActiveRecord::StatementInvalid
error.
Information I've found around this suggests a ROLLBACK or RELEASE SAVEPOINT after the failed INSERT, but I'm not sure how I would accomplish that here.
The aforementioned method:
def self.enqueue(updatable:, action:)
DelayedSync.create(updatable: updatable, status: :queued, action: action)
rescue ActiveRecord::RecordNotUnique
queued_update = DelayedSync.find_by(updatable: updatable, status: :queued, action: :sync_update)
if action == :sync_delete && queued_update.present?
queued_update.sync_delete!
else
Rails.logger.debug "#{updatable.class.name} #{updatable.id} already queued for sync, skipping."
end
end

Answer 1

Rather than rely on exception handling for logic, you can use ActiveRecord transactions to ensure all-or-nothing updates.
Like this:
ActiveRecord::Base.transaction do
DelayedSync.create!(updatable: updatable, status: :queued, action: action)
end
You can still safely utilize rescue to handle logging cleanup.
Docs that have much more detail about this can be found here.

Answer 2

After further digging, I uncovered the problem was due to how I was invoking this method from an after_save callback. Rails invokes after_save and after_destroy callbacks before the transaction has been closed. Rescuing the ActiveRecord::RecordNotUnique error invoked from this callback and attempting to execute more queries is impossible with Postgres, since it invalidates the entire transaction. My solution was to transition to the after_commit callback which provides the same control as after_save and after_destroy with the on: [:create, :destroy] parameter, with the benefit of being executed after the transaction (invalid or not) has closed.
This blog post is a bit dated, but the information near the bottom was immensely helpful and still holds true: http://markdaggett.com/blog/2011/12/01/transactions-in-rails/