Callbacks overview in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a before_save callback returns false?

In Rails, if a before_save callback returns false, what is the effect on the save operation?

Ruby on Rails

class User < ApplicationRecord
  before_save :check_status

  def check_status
    return false if inactive?
  end
end

user = User.new(status: 'inactive')
user.save

A The save operation continues normally and the record is saved.

B The save operation is aborted and the record is not saved.

C An exception is raised stopping the save operation.

D The callback is ignored and save proceeds.

💡 Hint

Think about how returning false in a before_save callback affects the transaction.

In Rails, returning false from a before_save callback halts the callback chain and prevents the save operation from completing.

📝 Syntax

intermediate

Which syntax correctly defines an after_commit callback?

Choose the correct way to define an after_commit callback in a Rails model.

A after_commit :send_notification

B after_commit do send_notification end

C after_commit -> { send_notification }

D after_commit :send_notification, on: :create

💡 Hint

Consider the options for specifying when the callback runs.

The after_commit callback can specify the timing with on: :create, on: :update, or on: :destroy. Option D correctly uses this syntax.

🔧 Debug

advanced

Why does this before_destroy callback not prevent deletion?

Given the following model, why does the record still get deleted despite the before_destroy callback?

Ruby on Rails

class Post < ApplicationRecord
  before_destroy :check_if_published

  def check_if_published
    throw(:abort) if published?
  end
end

post = Post.find(1)
post.destroy

A The <code>published?</code> method always returns false, so deletion proceeds.

B The callback uses <code>throw(:abort)</code> which is correct, so the record should not be deleted.

C The callback should return false instead of throwing :abort to stop deletion.

D The callback is not registered properly because it lacks <code>self.</code> prefix.

💡 Hint

Check the condition inside the callback method.

If published? returns false, the throw(:abort) is never called, so the deletion proceeds.

❓ state_output

advanced

What is the value of status after save with after_save callback?

Consider this model with an after_save callback that changes an attribute. What is the value of status after save completes?

Ruby on Rails

class Task < ApplicationRecord
  after_save :mark_completed

  def mark_completed
    update_column(:status, 'completed')
  end
end

task = Task.create(status: 'pending')
task.reload
status_value = task.status

A "completed"

B Raises an error due to recursive update

C nil

D "pending"

💡 Hint

Think about when after_save runs and what update_column does.

The after_save callback runs after the initial save. The update_column updates the attribute directly in the database without callbacks, so after reload, status is "completed".

🧠 Conceptual

expert

Which callback ensures code runs only after a successful database commit?

In Rails, which callback guarantees that the code inside it runs only after the database transaction has been successfully committed?

A after_create

B after_save

C after_commit

D after_validation

💡 Hint

Think about the difference between saving and committing a transaction.

after_commit runs only after the database transaction is fully committed, ensuring data is saved permanently.

Practice

1. What is the main purpose of callbacks in Rails models?

easy

A. To run code automatically at specific points in a model's life

B. To manually call methods from controllers

C. To style the HTML output of views

D. To handle database migrations

Solution

1. Step 1: Understand what callbacks do

   Callbacks are hooks that run code automatically during certain model events like saving or deleting.

2. Step 2: Identify the correct purpose

   Callbacks help automate tasks at specific points in a model's lifecycle, not manual calls or styling.

3. Final Answer:

   To run code automatically at specific points in a model's life -> Option A

4. Quick Check:

   Callbacks = automatic code run [OK]

Hint: Callbacks run code automatically at model events [OK]

Common Mistakes:

• Confusing callbacks with controller methods
• Thinking callbacks style views
• Mixing callbacks with database migrations

2. Which of the following is the correct syntax to define a callback that runs before saving a record?

easy

A. on_save :method_name

B. after_save :method_name

C. before_save do method_name end

D. before_save :method_name

Solution

1. Step 1: Recall callback syntax

   Rails uses before_save :method_name to run a method before saving a record.

2. Step 2: Check other options

   after_save runs after saving, on_save is invalid, and the block syntax is incorrect here.

3. Final Answer:

   before_save :method_name -> Option D

4. Quick Check:

   before_save syntax = before_save :method_name [OK]

Hint: Use before_save :method_name to run code before saving [OK]

Common Mistakes:

• Using after_save instead of before_save
• Trying to use on_save which doesn't exist
• Incorrect block syntax for callbacks

3. Given this model code:

class User < ApplicationRecord
  before_create :set_default_role

  def set_default_role
    self.role ||= 'guest'
  end
end

What will be the role of a new User if none is set before saving?

medium

A. 'guest'

B. 'admin'

C. nil

D. Raises an error

Solution

1. Step 1: Understand before_create callback

   The before_create callback runs the method set_default_role before the record is created in the database.

2. Step 2: Analyze set_default_role method

   The method sets self.role to 'guest' only if it is currently nil or falsey (using ||=).

3. Final Answer:

   'guest' -> Option A

4. Quick Check:

   before_create sets role to 'guest' if none set [OK]

Hint: before_create sets default values if none exist [OK]

Common Mistakes:

• Assuming role stays nil if not set
• Confusing before_create with after_create
• Thinking it raises an error without role

4. Identify the error in this callback definition:

class Post < ApplicationRecord
  before_save :check_title

  def check_title
    if title.blank?
      errors.add(:title, "can't be blank")
      throw :abort
    end
  end
end

medium

A. Using throw :abort is incorrect to stop save

B. No error, this is correct usage

C. Callback method should be private

D. errors.add should be errors.add_error

Solution

1. Step 1: Review callback usage

   The before_save callback runs check_title before saving.

2. Step 2: Check error handling

   Adding errors and using throw :abort is the correct way to stop saving if validation fails.

3. Final Answer:

   No error, this is correct usage -> Option B

4. Quick Check:

   throw :abort stops save correctly [OK]

Hint: Use throw :abort to halt save in callbacks [OK]

Common Mistakes:

• Thinking throw :abort is invalid
• Believing errors.add needs a different method
• Assuming callback methods must be private

5. You want to run a method log_update only after a record is updated but not created. Which callback should you use?

hard

A. before_save

B. after_save

C. after_update

D. before_update

Solution

1. Step 1: Understand callback timing

   after_save runs after both create and update, but after_update runs only after updates.

2. Step 2: Choose callback for updates only

   Since you want to run log_update only after updates, after_update is the correct choice.

3. Final Answer:

   after_update -> Option C

4. Quick Check:

   after_update runs only after updates [OK]

Hint: Use after_update for actions only after updates [OK]

Common Mistakes:

• Using after_save which runs on create too
• Choosing before_update which runs before update
• Confusing before_save with after_update