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.