Job retries and error handling in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a job raises an exception in Active Job with default retry settings?

Consider a Rails Active Job that raises an exception during execution. What is the default behavior regarding retries and job failure?

Ruby on Rails

class ExampleJob < ApplicationJob
  def perform
    raise "Something went wrong"
  end
end

ExampleJob.perform_later

A The job fails immediately without any retries.

B The job is retried automatically 3 times before being discarded.

C The job is retried infinitely until it succeeds.

D The job is retried once and then discarded.

💡 Hint

Active Job does not retry by default; retry_on must be configured.

By default, without retry_on, Active Job does not retry jobs that raise an exception; the job fails immediately.

📝 Syntax

intermediate

Which syntax correctly sets a custom retry count for a job in Rails Active Job?

You want to configure a job to retry only 5 times on failure. Which code snippet correctly sets this retry count?

A

class CustomRetryJob < ApplicationJob
  retry_on StandardError, attempts: 5
  def perform
    # job code
  end
end

B

class CustomRetryJob < ApplicationJob
  retry_on StandardError, retries: 5
  def perform
    # job code
  end
end

C

class CustomRetryJob < ApplicationJob
  retry_on StandardError, max_retries: 5
  def perform
    # job code
  end
end

D

class CustomRetryJob < ApplicationJob
  retry_on StandardError, retry_count: 5
  def perform
    # job code
  end
end

💡 Hint

Check the official Active Job retry_on method options.

The correct option uses attempts: 5 to set the retry count.

🔧 Debug

advanced

Why does this job never retry despite using retry_on?

Given the following job code, why does the job not retry after raising a RuntimeError?

Ruby on Rails

class NoRetryJob < ApplicationJob
  retry_on ArgumentError, attempts: 3

  def perform
    raise RuntimeError, "fail"
  end
end

A Because RuntimeError is a subclass of ArgumentError, so it skips retry.

B Because retry_on is set only for ArgumentError, not RuntimeError.

C Because retry_on requires a block to retry the job.

D Because attempts option is ignored for RuntimeError exceptions.

💡 Hint

Check which exception class retry_on is configured to handle.

The job only retries on ArgumentError, but it raises RuntimeError, so no retry happens.

❓ state_output

advanced

What is the state of a job after all retries are exhausted?

If a job configured with retry_on fails all retry attempts, what is the final state of the job in the queue system?

A The job remains in the queue indefinitely waiting for manual retry.

B The job is automatically rescheduled to run again after a delay.

C The job is marked as failed and moved to the dead queue or discarded.

D The job is deleted immediately without any record.

💡 Hint

Think about what happens when retries are exhausted in background job systems.

After all retries, the job is marked failed and usually moved to a dead queue or discarded.

🧠 Conceptual

expert

How can you implement exponential backoff for retries in Rails Active Job?

You want your job retries to wait longer after each failure, doubling the wait time each retry (exponential backoff). Which approach correctly implements this behavior?

A Override the perform method to sleep for an exponentially increasing time before raising an error.

B Set attempts to a high number and rely on default retry intervals for exponential backoff.

C Use discard_on with a delay option that increases exponentially.

D Use retry_on with a block that re-enqueues the job with increasing wait times based on the retry count.

💡 Hint

Consider how retry_on blocks can customize retry behavior and delay.

retry_on accepts a block where you can control the retry delay dynamically based on the retry count, enabling exponential backoff.

Practice

1. What does the retry_on method do in a Rails Active Job?

easy

A. It retries the job automatically if a specified error occurs.

B. It discards the job immediately without retrying.

C. It schedules the job to run only once without retries.

D. It logs the error but does not retry the job.

Solution

1. Step 1: Understand retry_on purpose

   The retry_on method tells Rails to retry a job if a certain error happens during execution.

2. Step 2: Compare with other options

   Unlike discard_on, which stops retries, retry_on allows automatic retrying.

3. Final Answer:

   It retries the job automatically if a specified error occurs. -> Option A

4. Quick Check:

   retry_on = automatic retry [OK]

Hint: Remember: retry_on means try again on error [OK]

Common Mistakes:

• Confusing retry_on with discard_on
• Thinking retry_on discards the job
• Assuming retry_on logs errors only

2. Which of the following is the correct syntax to retry a job on ActiveRecord::Deadlocked error with 3 attempts in Rails?

easy

A. retry_on(ActiveRecord::Deadlocked, attempts: 3)

B. retry_on ActiveRecord::Deadlocked attempts=3

C. retry_on ActiveRecord::Deadlocked attempts: 3

D. retry_on(ActiveRecord::Deadlocked attempts: 3)

Solution

1. Step 1: Recall method call syntax in Ruby

   Methods with arguments and options require parentheses for clarity, especially with keyword arguments.

2. Step 2: Check each option's syntax

   retry_on(ActiveRecord::Deadlocked, attempts: 3) uses parentheses and correct keyword argument syntax: retry_on(ActiveRecord::Deadlocked, attempts: 3).

3. Final Answer:

   retry_on(ActiveRecord::Deadlocked, attempts: 3) -> Option A

4. Quick Check:

   Correct method call syntax = retry_on(ActiveRecord::Deadlocked, attempts: 3) [OK]

Hint: Use parentheses with keyword args for retry_on [OK]

Common Mistakes:

• Omitting parentheses with keyword arguments
• Using equal sign instead of colon for options
• Missing commas between arguments

3. Given this job code:

class MyJob < ApplicationJob
  retry_on StandardError, attempts: 2

  def perform
    raise StandardError, "fail"
  end
end

MyJob.perform_now

What happens when MyJob.perform_now is called?

medium

A. The job silently discards the error and finishes.

B. The job raises StandardError once and stops.

C. The job retries twice after failures, then raises error.

D. The job retries once after the first failure, then raises error.

Solution

1. Step 1: Understand retry_on with attempts: 2

   It means the job will try up to 2 times total (1 initial + 1 retry) before giving up.

2. Step 2: Analyze job behavior

   The job raises StandardError every time. It runs once, fails, retries once, then fails again and raises error.

3. Final Answer:

   The job retries once after the first failure, then raises error. -> Option D

4. Quick Check:

   attempts: 2 means 1 retry [OK]

Hint: attempts count includes first try, so retries = attempts - 1 [OK]

Common Mistakes:

• Thinking attempts means retries count
• Assuming job discards error automatically
• Believing job retries infinitely

4. Identify the error in this job code snippet:

class ExampleJob < ApplicationJob
  retry_on(StandardError, attempts: 3)

  def perform
    # job logic
  end
end

medium

A. The retry_on method should be called inside perform method.

B. The retry_on method should not have parentheses.

C. The retry_on method is correctly used; no error.

D. The retry_on method should be declared with a block.

Solution

1. Step 1: Check retry_on usage location

   retry_on is a class-level method and should be declared outside perform method, as shown.

2. Step 2: Verify syntax correctness

   Using parentheses with arguments is valid Ruby syntax here.

3. Final Answer:

   The retry_on method is correctly used; no error. -> Option C

4. Quick Check:

   retry_on class method syntax is correct [OK]

Hint: retry_on is a class method, not inside perform [OK]

Common Mistakes:

• Placing retry_on inside perform method
• Thinking parentheses are disallowed
• Expecting retry_on to require a block

5. You want a job to retry up to 5 times on Net::OpenTimeout errors but discard immediately on ArgumentError. Which code correctly implements this behavior?

hard

A. class NetworkJob < ApplicationJob
discard_on Net::OpenTimeout
retry_on ArgumentError, attempts: 5

def perform
# network call
end
end

B. class NetworkJob < ApplicationJob
retry_on Net::OpenTimeout, attempts: 5
discard_on ArgumentError

def perform
# network call
end
end

C. class NetworkJob < ApplicationJob
retry_on Net::OpenTimeout
retry_on ArgumentError, attempts: 5

def perform
# network call
end
end

D. class NetworkJob < ApplicationJob
discard_on Net::OpenTimeout, attempts: 5
discard_on ArgumentError

def perform
# network call
end
end

Solution

1. Step 1: Understand retry_on and discard_on roles

   retry_on retries job on specified error; discard_on stops retries and discards job immediately.

2. Step 2: Match errors to correct methods

   Net::OpenTimeout should retry up to 5 times, so use retry_on with attempts: 5. ArgumentError should discard immediately, so use discard_on.

3. Final Answer:

   Code with retry_on Net::OpenTimeout, attempts: 5 and discard_on ArgumentError -> Option B

4. Quick Check:

   retry_on for retry, discard_on for discard [OK]

Hint: retry_on = retry; discard_on = stop and discard [OK]

Common Mistakes:

• Swapping retry_on and discard_on for errors
• Missing attempts option for retry_on
• Using discard_on with attempts option