LangGraph Runtime: Persistence, HITL & Streaming: interview questions

Production questions of the kind asked in applied AI engineering interviews.

1. Finance reports that refund-99 was paid out twice, and the billing team says it got two approval requests for it. The approval itself was given once. How do you investigate?

What a strong answer covers:

• Reads the thread's checkpoint history and the provider's logs side by side, and counts how many times human_gate and execute ran
• Knows that resuming after interrupt() re-runs the gate node from its first line, so a notification above the call goes out again
• Knows that a RetryPolicy or an invoke(None) after a crash re-runs execute, and a provider that applied the refund but lost the response gets called twice
• Fixes both at the source: the notice moves to its own node before the gate, and the refund call carries an idempotency key such as refund:refund-99 that the provider dedups on

2. High-risk refunds wait up to two days for approval, and the service runs on three workers that redeploy daily. The prototype uses InMemorySaver. What do you change, and what do you check before launch?

What a strong answer covers:

• InMemorySaver lives in one process; a redeploy loses every parked refund, and a resume that lands on another worker finds no thread
• Moves to a shared durable saver (PostgresSaver for several writers; SqliteSaver is fine for one process on one machine), with no change to graph code
• Tests the restart path: start refund-99, kill the worker, resume from a fresh process with the same thread_id
• Plans retention: checkpoints accumulate per step, so old finished threads need a cleanup job

3. Your manager wants a dashboard showing how many refunds are waiting for approval and for how long. Where does the data come from?

What a strong answer covers:

• A thread parked at the gate has get_state(config).next == ("human_gate",) and a pending interrupt in its tasks
• The latest checkpoint's created_at gives the wait time; alerts fire when a refund waits past an agreed limit
• Keeps an append-only events field (an operator.add reducer) as the audit trail, since values alone shows only the latest state
• Records the decision and who made it in state when resuming, so the dashboard and the audit agree

4. A refund was assessed as high risk on Friday and approved on Monday. Over the weekend the policy team changed the refund window. Which policy applies when the graph resumes, and should it?

What a strong answer covers:

• The checkpoint holds Friday's state; resuming continues from it and does not re-run triage or assess
• Decides whether stale assessments are acceptable; for money, re-checks the policy in execute or routes back to assess when the policy version changed
• Stores the policy version in state at assessment time, so the check is a comparison, not a guess
• For a deliberate correction, forks with update_state from the checkpoint before execute instead of editing the database

5. The support chat streams tokens with stream_mode="messages". After a grader node was added, customers briefly see "yes relevant" before the answer. Why, and how do you fix it?

What a strong answer covers:

• messages mode streams tokens from every chat-model call inside every node, the grader included
• Each chunk comes with metadata; filters on metadata["langgraph_node"] == "answer" before rendering
• Uses updates mode in parallel for progress labels ("checking the handbook"), passing a list of modes and reading (mode, chunk) pairs
• Adds a test that streams a scripted run and asserts no grader tokens reach the client