29
.
04
.
2024
26
.
09
.
2022
Ruby on Rails
Backend
Ruby
Tutorial

How to rescue a transaction to roll back changes?

Paweł Strzałkowski
Chief Technology Officer

The documentation is clear and the answer seems to be obvious. However, as I'm discussing this matter quite frequently, it turns out that some people need a small clarification. I have decided that today is the last day when I explain this issue to anyone. From now on, I will be sending a link to this article and feel exempted from further explanations.

Rescue which does not work as you wish

The following example does not roll back your post object.


ActiveRecord::Base.transaction do
  post.update!(title: "cow")
  post.update!(content: "beer")

  raise StandardError, "cow and beer are not compatible"
rescue StandardError => e
  Rails.logger.error(e.message)
end

The error is rescued and handled. It is not propagated beyond the rescue block. As a result, it doesn't affect the transaction block.

Example

As a quick example, let's create a post with a title and some content. In a transaction block, it is updated twice and then an error is raised. The error is rescued and you can clearly see a COMMIT statement in the SQL log. You can also read the updated values from the post object.

If you intended it to roll back the transaction - it just does not work like that.


> post = Post.create(title: 'bee', content: 'honey')

TRANSACTION (0.1ms)  BEGIN
Post Create (0.6ms)  INSERT INTO "posts"("title", "content", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id"  [["title", "bee"], ["content", "honey"], ["created_at", "2022-09-19 13:52:12.518986"], ["updated_at", "2022-09-19 13:52:12.518986"]]
TRANSACTION (2.0ms)  COMMIT
 => #<Post:0x0000000112f4ea30 id: 3, title: "bee", content: "honey", created_at: Mon, 19 Sep 2022 13:52:12.518986000 UTC +00:00, updated_at: Mon, 19 Sep 2022 13:52:12.518986000 UTC +00:00>

> ActiveRecord::Base.transaction do
>   post.update!(title: "cow")
>   post.update!(content: "beer")
>
>   raise StandardError, "cow and beer are not compatible"
> rescue StandardError => e
>   Rails.logger.error(e.message)
> end

TRANSACTION (0.1ms)  BEGIN
  Post Update (0.3ms)  UPDATE "posts" SET "title" = $1, "updated_at" = $2 WHERE "posts"."id" = $3  [["title", "cow"], ["updated_at", "2022-09-19 13:52:17.956795"], ["id", 3]]
  Post Update (0.2ms)  UPDATE "posts" SET "content" = $1, "updated_at" = $2 WHERE "posts"."id" = $3  [["content", "beer"], ["updated_at", "2022-09-19 13:52:17.958060"], ["id", 3]]
cow and beer are not compatible
  TRANSACTION (2.0ms)  COMMIT
 => 32

> post.reload
  Post Load (0.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = $1 LIMIT $2  [["id", 3], ["LIMIT", 1]]
 => #<Post:0x0000000112f4ea30 id: 3, title: "cow", content: "beer", created_at: Mon, 19 Sep 2022 13:52:12.518986000 UTC +00:00, updated_at: Mon, 19 Sep 2022 13:52:17.958060000 UTC +00:00>

A working example of a transaction rollback


begin
  ActiveRecord::Base.transaction do
    post.update!(title: "cow")
    post.update!(content: "beer")

    raise StandardError, "cow and beer are not compatible"
  end
rescue StandardError => e
  Rails.logger.error(e.message)
end

In this case, the error affects the transaction block and stops it from being committed. Later, the error is cached by the rescue instruction and handled appropriately.

Example

Let's use a similar example. In the transaction block, we update the post twice and then raise an error. The error is rescued outside of the transaction and you can see the ROLLBACK statement in the SQL log. You can also read the final values from the post object and see they were not changed.

If you intended it to roll back the transaction - congratulations, well done!


> post = Post.create(title: 'bee', content: 'honey')

TRANSACTION (0.1ms)  BEGIN
Post Create (0.2ms)  INSERT INTO "posts" ("title", "content", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id"  [["title", "bee"], ["content", "honey"], ["created_at", "2022-09-19 13:59:45.933973"], ["updated_at", "2022-09-19 13:59:45.933973"]]
TRANSACTION (2.1ms)  COMMIT
 => #<Post:0x0000000112d4f298 id: 4, title: "bee", content: "honey", created_at: Mon, 19 Sep 2022 13:59:45.933973000 UTC +00:00, updated_at: Mon, 19 Sep 2022 13:59:45.933973000 UTC +00:00>

> begin
>   ActiveRecord::Base.transaction do
>     post.update!(title: "cow")
>     post.update!(content: "beer")
>
>     raise StandardError, "cow and beer are not compatible"
>   end
> rescue StandardError => e
>   Rails.logger.error(e.message)
> end
  TRANSACTION (0.2ms)  BEGIN
  Post Update (0.4ms)  UPDATE "posts" SET "title" = $1, "updated_at" = $2 WHERE "posts"."id" = $3  [["title", "cow"], ["updated_at", "2022-09-19 13:59:53.937241"], ["id", 4]]
  Post Update (0.2ms)  UPDATE "posts" SET "content" = $1, "updated_at" = $2 WHERE "posts"."id" = $3  [["content", "beer"], ["updated_at", "2022-09-19 13:59:53.939197"], ["id", 4]]
  TRANSACTION (0.1ms)  ROLLBACK
cow and beer are not compatible
 => 32

> post.reload
  Post Load (0.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = $1 LIMIT $2  [["id", 4], ["LIMIT", 1]]
 => #<Post:0x0000000112d4f298 id: 4, title: "bee", content: "honey", created_at: Mon, 19 Sep 2022 13:59:45.933973000 UTC +00:00, updated_at: Mon, 19 Sep 2022 13:59:45.933973000 UTC +00:00>

Is rescuing within the block ever correct?

Definitely. There are numerous use cases where it is the correct approach. It allows you to ignore some of the errors and let the transaction commit. You may have additional logic in such a rescue block to decide the fate of the transaction. But please, use it wisely. If you have any doubts, check the logs for TRANSACTION COMMIT or ROLLBACK entries.

Happy Coding!

Paweł Strzałkowski
Chief Technology Officer

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

JSON:API consumption in Rails

14
.
11
.
2023
Jan Matusz
Ruby on Rails
Backend
Tutorial

Marketing hacks #01: How to Track off-line conversions

14
.
11
.
2023
Marek Łukaszuk
Ruby on Rails
Business
Marketing

Common communication issues in project management

02
.
10
.
2024
Michał Krochecki
Project Management

Selected SXSW lectures takeaways

14
.
11
.
2023
Michał Piórkowski
Conferences
Frontend
Backend
Business

SXSW Summary

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Conferences
Frontend
Backend
Business

How to get the most out of SXSW Interactive

02
.
10
.
2024
Michał Krochecki
Ruby on Rails
Conferences
Frontend
Backend
Business

Guide to recruitment at Visuality

14
.
11
.
2023
Michał Piórkowski
HR
Visuality

TOP Ruby on Rails Developers

14
.
11
.
2023
Maciej Zdunek
Ruby on Rails
Visuality
Business

How to conquer Westworld?

14
.
11
.
2023
Maciej Zdunek
Business
Marketing

2018 Rewind by Visuality

02
.
10
.
2024
Michał Krochecki
HR
Visuality

Quality Assurance Testing

14
.
11
.
2023
Jarosław Kowalewski
Ruby on Rails
Backend

Why do we like to be together?

02
.
10
.
2024
Michał Krochecki
Visuality
HR

Wallboards - a great value for our teams and clients

02
.
10
.
2024
Michał Krochecki
Ruby on Rails
Design
Project Management
Backend

2018 Clutch Global Leader

14
.
11
.
2023
Maciej Zdunek
Ruby on Rails
Visuality
Business
Marketing

Hot topic: Progressive Web Apps instead of native mobile apps

02
.
10
.
2024
Michał Krochecki
Ruby on Rails
Business
Backend
Frontend

Docker hosted on Jelastic

14
.
11
.
2023
Marcin Prokop
Ruby on Rails
Backend
Tutorial

All the pieces matter - Visuality DNA

14
.
11
.
2023
Michał Piórkowski
Visuality
HR

Tech conferences 2018/2019 you definitely should attend

02
.
10
.
2024
Michał Krochecki
Conferences

Visuality Poznań is here!

14
.
11
.
2023
Michał Piórkowski
Visuality
Business
HR

Why we chose Ruby on Rails and React.js for our main technologies? (FAQ).

02
.
10
.
2024
Michał Krochecki
Ruby on Rails
Backend
Frontend
Visuality

Branding: How to style your Jira?

14
.
11
.
2023
Lukasz Jackiewicz
Tutorial
Design
Project Management

How to start your UX/UI designer career

14
.
11
.
2023
Bartłomiej Bednarski
Design
Tutorial
HR