Scheduled jobs in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a scheduled job is enqueued with Active Job and Sidekiq?

Consider a Rails app using Active Job with Sidekiq as the backend. If you schedule a job with MyJob.set(wait: 5.minutes).perform_later, what will happen?

Ruby on Rails

class MyJob < ApplicationJob
  queue_as :default

  def perform
    puts "Job executed"
  end
end

MyJob.set(wait: 5.minutes).perform_later

A The job is scheduled to be pushed to Sidekiq after 5 minutes, then executed.

B The job is scheduled in Sidekiq but will never execute because Sidekiq does not support delayed jobs.

C The job is immediately pushed to Sidekiq and executed right away.

D The job is executed immediately in the current process without Sidekiq involvement.

💡 Hint

Think about how Active Job and Sidekiq handle delayed execution.

Using set(wait: 5.minutes) schedules the job to be enqueued in Sidekiq after 5 minutes. Sidekiq then executes the job asynchronously.

📝 Syntax

intermediate

Which syntax correctly schedules a recurring job with the 'whenever' gem?

You want to run a rake task every day at 2am using the 'whenever' gem. Which syntax in schedule.rb is correct?

A

every :day, at: '2:00 am' do
  rake 'my:task'
end

B

every 1.day, at: '02:00' do
  rake 'my:task'
end

C

every 1.day, at: '2:00 am' do
  rake 'my:task'
end

D

every :day, at: '02:00 am' do
  rake 'my:task'
end

💡 Hint

Check the symbol and time format used by 'whenever' for scheduling.

The 'whenever' gem uses symbols like :day and time strings like '2:00 am' for scheduling.

🔧 Debug

advanced

Why does this scheduled job never run in production?

Given this Sidekiq scheduled job code, why might the job never execute in production?

Ruby on Rails

class CleanupJob < ApplicationJob
  queue_as :default

  def perform
    # cleanup logic
  end
end

# Scheduling the job
CleanupJob.set(wait_until: Time.now + 1.hour).perform_later

A The job is scheduled with <code>wait_until</code> but this option is not supported by Active Job.

B The job is scheduled but the perform method is empty, so Sidekiq skips execution.

C The job is scheduled correctly but the queue name is wrong, so Sidekiq ignores it.

D Sidekiq is not running in production, so scheduled jobs are never processed.

💡 Hint

Check if the background worker process is active in production.

If Sidekiq is not running, scheduled jobs remain in Redis but are never executed.

❓ state_output

advanced

What is the state of the job after calling perform_later with a delay?

In a Rails app using Active Job with Sidekiq, what is the state of the job immediately after calling MyJob.set(wait: 10.minutes).perform_later?

Ruby on Rails

class MyJob < ApplicationJob
  def perform
    puts "Running job"
  end
end

MyJob.set(wait: 10.minutes).perform_later

A The job is saved in the database but not enqueued until manually triggered.

B The job is enqueued in Sidekiq's scheduled set and will run after 10 minutes.

C The job is enqueued in Sidekiq's default queue and runs immediately.

D The job is executed immediately in the current thread and then enqueued.

💡 Hint

Think about how Sidekiq handles delayed jobs internally.

Sidekiq stores delayed jobs in a scheduled set and only moves them to the queue when the delay expires.

🧠 Conceptual

expert

Which approach ensures a scheduled job runs exactly once even if the server restarts?

You want to schedule a job to run once at a specific time, and ensure it does not run multiple times if the server restarts or the job is retried. Which approach is best?

A Schedule the job with Active Job's <code>set(wait_until: time)</code> and trust Sidekiq to handle duplicates.

B Use Sidekiq's <code>perform_in</code> method to schedule the job and rely on Sidekiq's retry mechanism.

C Use a database-backed scheduler like <code>sidekiq-scheduler</code> with unique job constraints to prevent duplicates.

D Manually check in the job's perform method if it has run before by querying Redis keys.

💡 Hint

Consider how to prevent duplicate jobs in distributed systems.

Using a database-backed scheduler with unique job constraints ensures exactly-once execution even if the server restarts or retries happen.

Practice

1. What is the main purpose of scheduled jobs in a Rails application?

easy

A. To manage database migrations automatically

B. To handle user authentication and sessions

C. To automate tasks to run at specific times without manual effort

D. To style the user interface dynamically

Solution

1. Step 1: Understand the role of scheduled jobs

   Scheduled jobs are designed to run tasks automatically at set times without needing a user to start them manually.

2. Step 2: Compare with other options

   User authentication, database migrations, and UI styling are handled by other parts of Rails, not scheduled jobs.

3. Final Answer:

   To automate tasks to run at specific times without manual effort -> Option C

4. Quick Check:

   Scheduled jobs automate tasks = C [OK]

Hint: Scheduled jobs run tasks automatically on a schedule [OK]

Common Mistakes:

• Confusing scheduled jobs with user authentication
• Thinking scheduled jobs handle database migrations
• Assuming scheduled jobs style the UI

2. Which of the following is the correct way to define a job class in Rails?

easy

A. def MyJob
# task code
end

B. class MyJob
def perform
# task code
end
end

C. module MyJob
def perform
# task code
end
end

D. class MyJob < ApplicationJob
def perform
# task code
end
end

Solution

1. Step 1: Check the inheritance pattern for jobs

   In Rails, jobs must inherit from ApplicationJob to integrate with Active Job framework.

2. Step 2: Verify the method definition

   The perform method defines the task to run. class MyJob < ApplicationJob def perform # task code end end correctly defines a class inheriting ApplicationJob with perform method.

3. Final Answer:

   class MyJob < ApplicationJob\n def perform\n # task code\n end\nend -> Option D

4. Quick Check:

   Job class inherits ApplicationJob = A [OK]

Hint: Jobs inherit ApplicationJob and define perform method [OK]

Common Mistakes:

• Defining job without inheriting ApplicationJob
• Using module instead of class for jobs
• Defining job as a method instead of a class

3. Given the following job class, what will be the output when MyJob.perform_now is called?

class MyJob < ApplicationJob
  def perform
    puts 'Job executed'
  end
end

medium

A. Job executed

B. No output, job runs silently

C. Error: perform method missing

D. Job executed asynchronously

Solution

1. Step 1: Understand perform_now behavior

   Calling perform_now runs the job immediately and synchronously, executing the perform method.

2. Step 2: Check the perform method output

   The perform method prints 'Job executed' to the console, so this string will appear as output.

3. Final Answer:

   Job executed -> Option A

4. Quick Check:

   perform_now runs perform immediately = B [OK]

Hint: perform_now runs job immediately and prints output [OK]

Common Mistakes:

• Thinking perform_now runs job silently
• Confusing perform_now with asynchronous perform_later
• Expecting an error due to missing method

4. Identify the error in this job scheduling code snippet:

class CleanupJob < ApplicationJob
  def perform
    User.delete_all
  end
end

# Schedule in config/schedule.rb
every 1.day do
  runner 'CleanupJob.perform_later'
end

medium

A. No error, code is correct

B. perform_later should be perform_now in schedule

C. Using runner instead of calling rake task

D. runner expects a method call, not a class method

Solution

1. Step 1: Examine the job class definition

   The class correctly inherits from ApplicationJob and defines the perform method.

2. Step 2: Verify scheduling syntax

   The config/schedule.rb uses standard Whenever syntax: every 1.day with runner 'CleanupJob.perform_later', which executes Ruby code to enqueue the job asynchronously. No errors present.

3. Final Answer:

   No error, code is correct -> Option A

4. Quick Check:

   runner 'Job.perform_later' in schedule.rb = D [OK]

Hint: runner 'Job.perform_later' correctly enqueues job [OK]

Common Mistakes:

• Thinking runner expects only instance methods
• Confusing runner with rake tasks
• Believing perform_later is invalid in cron schedules

5. You want to schedule a job that runs every day at midnight to archive old records. Which of these is the best way to set this up using the whenever gem?

class ArchiveJob < ApplicationJob
  def perform
    Record.archive_old
  end
end

# config/schedule.rb
?

Which snippet correctly schedules the job?

hard

A. every 1.day, at: '12:00 pm' do
runner 'ArchiveJob.perform_later'
end

B. every :day, at: '00:00' do
runner 'ArchiveJob.perform_later'
end

C. every 24.hours do
rake 'archive:old_records'
end

D. every :midnight do
runner 'ArchiveJob.perform_now'
end

Solution

1. Step 1: Check whenever syntax for daily jobs at midnight

   The whenever gem uses symbols like :day and time strings like '00:00' to schedule jobs at midnight.

2. Step 2: Verify the job call method

   Using perform_later runs the job asynchronously, which is preferred for scheduled jobs to avoid blocking.

3. Step 3: Compare options

   every :day, at: '00:00' do runner 'ArchiveJob.perform_later' end uses correct symbol :day, time '00:00', and perform_later with runner, matching best practice.

4. Final Answer:

   every :day, at: '00:00' do\n runner 'ArchiveJob.perform_later'\nend -> Option B

5. Quick Check:

   whenever daily at midnight with perform_later = D [OK]

Hint: Use :day and '00:00' with perform_later in whenever [OK]

Common Mistakes:

• Using perform_now instead of perform_later for scheduled jobs
• Incorrect time format like '12:00 am' instead of '00:00'
• Using rake task instead of runner for Active Job