Merge pull request #26382 from naw/transaction-callback-docs

Update ActiveRecord callback guide for exceptions [ci skip]

2 files changed, 9 insertions, 1 deletions

diff --git a/guides/source/5_0_release_notes.md b/guides/source/5_0_release_notes.md
index 9c5ffb1d94..6538629972 100644
--- a/guides/source/5_0_release_notes.md
+++ b/guides/source/5_0_release_notes.md
@@ -797,6 +797,14 @@ Please refer to the [Changelog][active-record] for detailed changes.
     than the current time.
     ([Pull Request](https://github.com/rails/rails/pull/18956))
 
+*   Change transaction callbacks to not swallow errors.
+    Before this change any errors raised inside a transaction callback
+    were getting rescued and printed in the logs, unless you used
+    the (newly deprecated) `raise_in_transactional_callbacks = true` option.
+
+    Now these errors are not rescued anymore and just bubble up, as the other callbacks.
+    ([commit](https://github.com/rails/rails/commit/07d3d402341e81ada0214f2cb2be1da69eadfe72))
+
 Active Model
 ------------
 
diff --git a/guides/source/active_record_callbacks.md b/guides/source/active_record_callbacks.md
index a7975c7772..2a1c960887 100644
--- a/guides/source/active_record_callbacks.md
+++ b/guides/source/active_record_callbacks.md
@@ -431,4 +431,4 @@ class PictureFile < ApplicationRecord
 end
 ```
 
-WARNING. The `after_commit` and `after_rollback` callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don't interfere with the other callbacks. As such, if your callback code could raise an exception, you'll need to rescue it and handle it appropriately within the callback.
+WARNING. The `after_commit` and `after_rollback` callbacks are called for all models created, updated, or destroyed within a transaction block. However, if an exception is raised within one of these callbacks, the exception will bubble up and any remaining `after_commit` or `after_rollback` methods will _not_ be executed. As such, if your callback code could raise an exception, you'll need to rescue it and handle it within the callback in order to allow other callbacks to run.