Solid Queue: background jobs
This course follows one hand-written job class, Partners::FetchSiteIconJob, from its call site to the Solid Queue tables that store it. It covers why the job receives a plain id, what perform_later writes to a SolidQueue::Job row, and the eleven tables a job moves through. It reads config/queue.yml, with its dispatcher and three worker pools. It explains Solid Queue's separate database connection in development and shows where this app uses retry_on, discard_on and limits_concurrency. A final challenge gathers these facts into one Ruby method.
What you'll learn
- ✓Why a job receives a record id and fetches the record with find_by at run time
- ✓What perform_later writes to SolidQueue::Job and SolidQueue::ReadyExecution rows
- ✓The eleven Solid Queue tables and how a job moves through its execution states
- ✓How config/queue.yml sets up the dispatcher, three worker pools and JOB_CONCURRENCY
- ✓Why Solid Queue's tables use their own connection and database in development
- ✓What retry_on, discard_on and limits_concurrency do and which jobs in this app use them
A job class written by hand, past mailer delivery
"Mailers: templates & async" traced Solid Queue through deliver_later, Action Mailer's wrapper around a job. This app also has five job classes of its own in app/jobs/: one grades challenge submissions, three handle partner work (site icons, certificate announcements, webhook delivery), and one…
Read the full lesson free →Curriculum
7 lessonsA job class written by hand, past mailer delivery
Reads Partners::FetchSiteIconJob and its call site, and why it receives partner.id instead of the partner object.
perform_later creates a SolidQueue::Job row you can inspect
Shows the SolidQueue::Job and ReadyExecution rows that perform_later creates once the development :async adapter is switched off.
Eleven installed tables: a job's state machine
Lists the eleven installed Solid Queue tables and how a job moves through one execution table at a time.
config/queue.yml: this app's dispatcher and worker settings
Reads config/queue.yml line by line: dispatcher polling, batch size, three worker pools and the JOB_CONCURRENCY variable.
Solid Queue's own database connection
Explains why Solid Queue uses a separate database in development and why production keeps its tables in the primary one.
retry_on, discard_on, limits_concurrency: where this app uses them
Covers retry_on, discard_on and limits_concurrency, which jobs in this app use them, and why FetchSiteIconJob needs none.
Putting it together: trace a job from call site to table
Recaps the path of one job from call site to table and sets a challenge method, describe_job_dispatch.