Does Huey Remember Between Runs? The Result Store Deletes on Read, and Periodic Tasks Discard Their Return.

Huey keeps three things in its storage backend: a queue of pending task calls, a schedule of delayed and periodic work, and a result store for return values. Because all three can live in Redis, Postgres, or SQLite, it is easy to assume the next run of a task can see what the last run produced. It cannot, at least not in the way an AI task needs. Huey stores delivery state and one return value per task. It does not store working context, and the one place a result does land is designed to give that value up exactly once.

What Huey actually persists

Calling a task-decorated function serializes the call and places it in the queue. The caller gets a Result handle immediately. A consumer dequeues the call, runs the function, and writes the return value into the result store under the task ID. The schedule side works the same way: delayed calls wait in a sorted set until they are due, and periodic tasks are enqueued by the consumer's scheduler on their crontab.

Read those three structures together and the scope is narrow and deliberate. The queue answers what should run next. The schedule answers when. The result store answers what one finished task returned, for whoever holds that task's handle. None of the three answers what a task learned while it ran, which records it already handled, or what the next run should do differently. That history is simply not a Huey concept.

The result store deletes on read

The sharpest detail is how results are retrieved. Huey's result store is destructive by default. Calling result.get() removes the value from the store once it is read. The Result object caches the value locally, but asking the store again for the same task ID returns nothing. Keeping the value requires passing preserve=True on the read, which means the default path is built for a single handoff: producer enqueues, consumer executes, caller collects, and the record is gone.

Two defaults narrow it further. A task that returns None stores nothing at all, unless the Huey instance is created with store_none=True. And with the plain Redis backend, results that nobody reads are never cleaned up, so they sit in a hash indefinitely, unread and unusable as shared state, until the expiring variant, RedisExpireHuey, deletes them on a TTL. In both directions the store behaves like a mailbox slot, not a memory: read it once and it empties, ignore it and it expires or piles up.

Errors follow the same single-task boundary. A failed attempt stores an error record with the exception and traceback. If a retry later succeeds, the success overwrites the error. That helps the caller of that one task. It gives the next scheduled run no record of what went wrong last time, why, or what was already tried.

Periodic tasks discard their return value entirely

Periodic tasks are where the gap matters most for automation, because they repeat by design. A periodic task takes no arguments, and its return value is discarded. It is never written to the result store, because there is no caller holding a handle to collect it. So the pattern used for a nightly AI job, a crontab-driven summarizer, a recurring triage task, runs in the mode where Huey keeps the least: the schedule entry fires, the function executes with no inputs beyond what the code itself fetches, and whatever it concluded leaves no trace in Huey at all.

An AI task inside that shape wakes up blank every cycle. It can re-read a database, a file, or an API if the code does that work each time. It can write its own notes somewhere if the code does that too. Huey itself supplies neither the reading nor the writing. The queue guarantees the task runs on time. It guarantees nothing about the task knowing it has run before.

What this means for AI tasks on Huey

None of this is a defect in Huey. It is a lightweight task queue, and it does the queue job well: minimal setup, several storage backends, retries, locking, rate limits, pipelines. The problem appears when an AI step is placed inside a task and the queue is expected to double as the agent's memory. The agent's real state, the decisions, the partial progress, the facts gathered across runs, has no home in the queue, the schedule, or a result store that deletes on read.

The usual workaround is a hand-built state table: a row per job type, updated by hand at the end of each run, read back at the start of the next one. That works until the second tool needs the same state, or the state stops fitting in a row of summary fields. What the agent actually produced was a conversation with the work: prompts, tool results, corrections, conclusions. Compressing that into a few columns loses exactly the context that would have made the next run good.

A memory layer the next run can actually read

Vilix AI is built to be that missing layer, sitting outside the queue so every run and every tool reads the same state. It is cloud-hosted with zero infrastructure to run: there is no server, database, or vector store to provision or maintain. Agents and tools connect over MCP, so the same memory is available everywhere the work happens, from a Huey consumer on a server to an assistant on a laptop or phone.

Vilix AI stores full conversation history, not just extracted facts. When a scheduled run ends, its actual exchange, what it was asked, what it found, what it decided, is saved as a conversation the next run can reopen and continue, instead of a one-line result that disappears on first read. A nightly task can close by saving its findings, and the morning run starts from those findings rather than from a blank function call.

Getting started takes minutes. The free plan is free forever, and the Pro plan comes with a 7-day trial with no credit card required. Your data stays yours: export everything or delete it anytime.

Get Started for Free Free forever, no credit card.

Keep Huey for what it is good at: running the task on time, retrying it when it fails, and handing one result back to one caller. Give the work between those runs a memory that survives the read.