AfterCommitQueue#run_after_commit_or_now does not handle nested transactions / unknown records
Related to #346309 (closed).
AfterCommitQueue#run_after_commit_or_now
Problems with -
run_after_commit_or_now
possibly has other problems. It can run immediately even if you are in a transaction because the outer transaction doesn't know about objects that have just been built -
Nested transactions can have undesirable behaviour where we run immediately even though we were hoping to run in the outer transaction if the record was part of the outer transaction
What to do?
This class isn't well documented or well tested and it's not clear what the intended behaviour is.
Potentially we can migrate run_after_commit_or_now
to the following ? See also !76407 (closed)
diff --git a/app/models/concerns/after_commit_queue.rb b/app/models/concerns/after_commit_queue.rb
index 7f525bec9e9..d5aa2cdeafe 100644
--- a/app/models/concerns/after_commit_queue.rb
+++ b/app/models/concerns/after_commit_queue.rb
@@ -19,11 +19,18 @@ def run_after_commit_or_now(&block)
if connection.current_transaction.records&.include?(self)
run_after_commit(&block)
else
+ ## TODO Test this out
+ ## TODO Analyze each usage
+ connection.add_transaction_record(self)
+
+ run_after_commit(&block)
+
+ ## LEGACY
# If the current transaction does not include this record, we can run
# the block now, even if it queues a Sidekiq job.
- Sidekiq::Worker.skipping_transaction_check do
- instance_eval(&block)
- end
+ #Sidekiq::Worker.skipping_transaction_check do
+ #instance_eval(&block)
+ #end
end
else
instance_eval(&block)