Scheduled jobs in Ruby on Rails - Step-by-Step Execution

Concept Flow - Scheduled jobs

Define job class

↓

Schedule job with interval

↓

Job queue stores job

↓

Background worker picks job

↓

Job performs task

↓

Job completes and logs

↓

Wait for next scheduled time

Scheduled jobs in Rails define tasks to run later or repeatedly, managed by background workers that pick and execute them on time.

Execution Sample

Ruby on Rails

class CleanupJob < ApplicationJob
  queue_as :default

  def perform
    User.where('last_sign_in_at < ?', 1.year.ago).delete_all
  end
end

CleanupJob.set(wait: 1.hour).perform_later

This code schedules a job to delete users inactive for over a year, running one hour later.

Execution Table

Step	Action	Job State	Worker Action	Output/Result
1	Define CleanupJob class	Job class ready	No worker action	Ready to schedule
2	Schedule job with wait: 1.hour	Job queued with timestamp	No worker action	Job stored in queue
3	Background worker checks queue	Job queued	No job ready yet	Wait for scheduled time
4	One hour passes	Job ready to run	Worker picks job	Job starts performing
5	Perform job: delete old users	Job running	Worker executes perform method	Old users deleted
6	Job completes	Job done	Worker logs completion	Job finished successfully
7	Wait for next scheduled job	No job queued	Idle or picks next job	Ready for next task

💡 Job finishes after performing task; worker waits for next scheduled job.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
Job State	Not defined	Queued with timestamp	Ready to run	Running	Done
Worker Status	Idle	Idle	Picks job	Executes job	Idle

Key Moments - 3 Insights

Why doesn't the job run immediately after scheduling?

Because the job is scheduled with a delay (wait: 1.hour), the worker waits until the scheduled time before running it, as shown in steps 3 and 4.

What happens if the worker checks the queue but the job is not ready?

The worker stays idle or checks other jobs until the scheduled time arrives, as seen in step 3 where no job runs yet.

How does the job know what task to perform?

The job class defines the perform method with the task code; the worker calls this method when running the job (step 5).

Visual Quiz - 3 Questions

Look at the execution table, what is the Job State at Step 4?

A Queued with timestamp

B Running

C Ready to run

D Done

💡 Hint

Check the 'Job State' column at Step 4 in the execution_table.

At which step does the worker start executing the job's perform method?

A Step 5

B Step 4

C Step 3

D Step 6

💡 Hint

Look for when 'Worker executes perform method' happens in the execution_table.

If the job was scheduled with wait: 0.seconds, how would Step 3 change?

A Job would remain queued longer

B Worker would pick job immediately, no waiting

C Worker would ignore the job

D Job would be deleted

💡 Hint

Consider the 'Job queued with timestamp' and worker action timing in Step 3.

Concept Snapshot

Scheduled jobs in Rails run tasks later or repeatedly.
Define a job class with perform method.
Schedule with set(wait: time).perform_later.
Background workers run jobs at scheduled time.
Useful for cleanup, emails, reports.

Full Transcript

Scheduled jobs in Rails let you run code later or repeatedly without blocking the main app. You create a job class inheriting from ApplicationJob and define a perform method with the task. Then you schedule it using set(wait: time).perform_later, which queues the job with a timestamp. Background workers check the queue and run jobs when their scheduled time arrives. This process helps keep your app responsive by handling tasks like deleting old users or sending emails in the background. The execution table shows each step from defining the job to completion, tracking job state and worker actions. Key points include understanding the delay before execution and how the worker picks and runs the job. This visual trace helps beginners see how scheduled jobs flow in Rails.

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