How do you resume a long-running LlamaIndex Workflow after the process restarts?

## Two different problems "Resume" means two things in LlamaIndex workflows, and interviews probe whether you separate them. 1. **Continuity of a conversation or a job across process boundaries.** The state you care about is what the steps accumulated: chat history, retrieved facts, counters, partial results. That lives in `Context`. 2. **Replaying a failed run from the step that failed** so you do not repeat expensive earlier steps. That is `WorkflowCheckpointer`. ## Context serialization A `Context` is the per-run shared object. Steps write to it with `await ctx.store.set(key, value)` and read with `await ctx.store.get(key)`. To carry it across runs, serialize: ``` ctx_dict = ctx.to_dict(serializer=JsonSerializer()) ``` Store that dict wherever your application keeps session state — Redis, Postgres, a document store; the framework does not choose for you. To resume: ``` ctx = Context.from_dict(workflow, ctx_dict, serializer=JsonSerializer()) result = await workflow.run(..., ctx=ctx) ``` Because the prebuilt agents are Workflows, the same pattern gives multi-turn agent memory: keep one `Context` per conversation, pass it into every `agent.run(...)`, and chat history plus any tool-written state persists. Serializer choice matters. `JsonSerializer` is safe and portable but only handles JSON-compatible values. A pickle-based serializer can round-trip richer objects at the usual cost — you are executing whatever is in the payload on load, so never restore untrusted bytes, and stored state becomes coupled to your class definitions. The disciplined answer is to keep only plain data in the store: strings, numbers, dicts, lists, and identifiers you can use to rebuild clients on the other side. ## WorkflowCheckpointer `WorkflowCheckpointer(workflow=my_workflow)` wraps a workflow. Run through the wrapper rather than the workflow directly, and after each completed step it records a checkpoint holding the last completed step's name, the input event, the output event and the serialized context state. The collected checkpoints are exposed on the checkpointer, grouped by run, and it can start a fresh run *from* a chosen checkpoint. This is invaluable when a workflow's third step is a slow, expensive LLM call and the fourth is the one you are iterating on — you replay from checkpoint three repeatedly instead of paying for the first three every edit. It is also how you triage a bad output: inspect the exact input event that the failing step received. The limitation to state plainly: checkpoints are accumulated by the checkpointer instance in memory. They are not a durable store, they grow with every step of every run, and they vanish with the process. Treating `WorkflowCheckpointer` as production fault tolerance is the mistake; treat it as a development and replay tool, and if you want durability, extract the checkpoint payloads and write them somewhere yourself. ## Human-in-the-loop is the same machinery A workflow that must wait for a person is a resume problem with a long gap. A step can emit an input-required event and wait for a human-response event; the run handler surfaces the request through the stream, and the answer is sent back into the context when it arrives. If the wait may outlive the process — an approval that takes hours — you serialize the context, drop the process, and rebuild the context when the human responds. That is why context serialization, not an in-memory pause, is the durable pattern. ## Design rules that keep this working - **Keep state small and plain.** Every megabyte in `ctx.store` is a megabyte serialized on each save. Store document ids, not documents. - **Never put live handles in the store.** Database sessions, HTTP clients and file objects do not serialize; rebuild them in the step from configuration. - **Version your state.** Restoring a context written by an older code path into a workflow whose steps now expect different keys fails at read time, in a step, not at load. Include a schema version and migrate or discard. - **Make steps idempotent where you can.** Resuming re-executes the step you resume into; if it charges a card or posts a message, guard it with a key you keep in the context. - **Watch the timeout.** The workflow timeout applies per run, so a resumed run gets a fresh budget — do not rely on it to bound total task time across resumes. ## What to say in an interview Name the two mechanisms, say which one is durable, and be explicit that persistence backend choice is yours: LlamaIndex gives you a serializable context and step snapshots, not a hosted state service. That distinction is what separates someone who has shipped a long-running workflow from someone who has read the quickstart.