Consider a Rails Active Job class SendEmailJob. When you call SendEmailJob.perform_later(user_id), what is the immediate behavior?
class SendEmailJob < ApplicationJob queue_as :default def perform(user_id) # send email logic end end SendEmailJob.perform_later(42)
Think about how perform_later differs from perform_now.
Calling perform_later enqueues the job to run asynchronously using the configured queue adapter. It does not run immediately.
Which of the following correctly sets the queue name to :mailers in a Rails Active Job class?
class NotificationJob < ApplicationJob # set queue here queue_as :mailers def perform # job code end end
Look for the official method to assign queue names in Active Job.
The queue_as method is the correct way to specify the queue name in an Active Job class.
Given the following job and code, why does the job never execute?
class CleanupJob < ApplicationJob queue_as :default def perform puts "Cleaning up..." end end CleanupJob.perform_later
Check if the background job processor is running or configured.
If no queue adapter or background worker is running, jobs are enqueued but never processed.
What will be printed when the following job is enqueued and performed?
class GreetJob < ApplicationJob def perform(name) puts "Hello, #{name}!" end end GreetJob.perform_now("Alice")
Consider how perform_now works with arguments.
The perform_now method runs the job immediately with the given argument, printing the greeting.
Among the default Rails queue adapters, which one supports automatic job retries without extra configuration?
Think about which adapter is designed for production background processing with retry features.
Sidekiq adapter supports retries natively by default, unlike Async or Inline adapters.