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.