Does Solid Queue Remember Between Runs? Jobs Are Stored in Your Database. The Next Job Still Starts With Only Its Arguments.

Solid Queue remembers jobs in a place that feels permanent: your own database. It is the database-backed Active Job backend that ships as the default in Rails 8, and every job is written as a row before a worker touches it. That row survives restarts, deploys, and crashed processes, so it is reasonable to assume the next run picks up where the last one left off. It does not. A worker claims a row, builds a fresh job object, and hands it one thing: the arguments stored with that row. Everything the previous job learned while it ran stays out of the next job unless application code saved it somewhere and the next job reads it back.

A job row holds an instruction, not a working memory

When code enqueues a job, Solid Queue writes a master record into the solid_queue_jobs table. That record holds the job class name, the serialized arguments, the queue name, the priority, an optional concurrency key, and timestamps. It is a complete instruction: which class to run, with which inputs.

Around that master record sit the execution tables, and each one describes delivery, not learning. A job due now waits in ready executions. A job due later waits in scheduled executions until a dispatcher moves it. A job a worker has picked up sits in claimed executions. A job stopped by a concurrency limit sits in blocked executions. A job that raised sits in failed executions, with the error kept for inspection.

Read those tables together and a clear picture forms. Solid Queue can answer where a job is, when it should run, whether it finished, and how it failed. No table answers what the job concluded, what it decided about a customer, or what the next job should do differently because of it. The record is built for delivery tracking. Reasoning never enters it.

Finished jobs stay in the table. Their results do not travel.

One detail makes the memory question confusing: by default, finished jobs are preserved. When a job completes, Solid Queue stamps its finished_at time and leaves the row in solid_queue_jobs instead of deleting it, until the rows are pruned. That looks like a history the system keeps for itself.

That preserved row is an audit trail for people, not a briefing for the next run. It keeps the same arguments the job started with, not a result the job produced. A job's return value is not written back into its row as input for a successor. A failed execution keeps its error, which supports a manual retry or discard decision in a dashboard. None of that is read automatically when the next job of the same class is claimed. Tuesday's job receives Tuesday's arguments, identical in kind to what Monday's job received, with no field that says what Monday's job found.

Retries follow the same rule. A retry re-runs the same job record with the same arguments. A new enqueue, even of the same class for the same application record, is a new row with its own arguments and no link to the earlier row's outcome.

Recurring tasks record that they ran, not what they learned

Solid Queue's recurring tasks make the boundary sharpest. Recurring tasks are defined in configuration with a schedule, a job class, and arguments, and a scheduler enqueues a fresh job each time one comes due. To stop the same slot being enqueued twice, Solid Queue writes a recurring execution row keyed by the task and its run time.

That row is a dedup guard. It proves this slot was already claimed, so a second scheduler does not create a duplicate job. It does not store the previous run's output, and the newly enqueued job does not read it for context. A daily job and its next daily instance share a task key and a schedule. They do not share findings. Each instance starts with the configured arguments, plus whatever the job code fetches for itself after it starts.

Concurrency controls tell the same story. A concurrency key can hold jobs back so only one runs at a time for a given record. That ordering protects shared data from parallel writes. It still passes nothing between the jobs it orders. The second job waits for the first to finish, then starts with only its own arguments, unaware of what the first one changed or decided unless it queries the application tables itself.

Where an AI step inside a Solid Queue job goes blind

Put a model call inside a Rails job and the gap becomes practical. Consider a recurring job that reviews new support tickets every morning, drafts replies, and flags accounts that need a person. On the first morning, the job's model step produces real judgments: this account was already promised a credit, that ticket was already taken over by a support lead, this question was already answered yesterday inside another tool.

The next morning, the scheduler enqueues a new job. Its arguments carry a date range or a batch of ticket IDs, not yesterday's judgments. Unless yesterday's job wrote those judgments into application tables that today's job loads before calling the model, today's step repeats settled work and can contradict a decision already made. Solid Queue stored every job row correctly. Remembering judgments was never assigned to it.

Give the job a memory it can read before it reasons

The clean split is delivery versus memory. Solid Queue handles delivery inside the database Rails already runs: enqueueing, claiming, scheduling, retrying, and recurring work. Memory needs a layer that every run, and every tool around the run, can read and write in one shared place.

Vilix AI is built for that second job. Vilix AI is cloud-hosted, so there is zero infrastructure to deploy or manage next to the queue database. The same memory is available everywhere over MCP, so a Solid Queue job, a chat assistant, a coding tool, and another scheduled agent can all work from one shared memory instead of separate notes. Vilix AI stores full conversation history, not just extracted facts, so a later run can revisit what was actually said and decided, in full context.

For the morning ticket job, the pattern is direct. Before the model reasons, the job retrieves the memory that matters: prior decisions for that account, earlier conversations, and rules settled in other tools. After it acts, it saves what it did and learned back to the same memory. The next scheduled instance then starts from that record, not from its arguments alone.

Vilix AI is free forever on the free plan, with a 7-day Pro trial that requires no credit card. Data can be exported or deleted at any time.

Solid Queue will keep remembering what it was designed to remember: a class, its arguments, a delivery state, and a durable row for each run. Give the AI steps inside those jobs a memory designed for reasoning, and each recurring run stops starting blind.