So is LangGraph a bad framework?

No — it was the wrong shape for this job. The pipeline was nearly linear, and the falsified design was one specific bet: END-terminated hops resumed by re-invoking a finished thread. The tell was that none of the capabilities that justify the framework — branching, human-in-the-loop, visualization — were ever used. Renting a framework for features you never call is the pattern, and it recurs.

What replaced checkpointing for crash recovery?

The database and the renderer itself. The stage field is written on every change; the render job row carries the prompt_id; the renderer's own history endpoint is the durable record of what finished. A kill -9 test after the rewrite showed the recovered process re-querying by prompt_id without resubmitting — submit_count stayed at 1. Recovery rebuilds from facts instead of replaying snapshots.

How do you catch the next mirage before it ships?

Two principles distilled from this incident now stand in the fleet constitution: import smoke is not a run, and a happy path is not validation — fault injection or it didn't happen. The general rule went further: form follows problem — define the problem, the scope, and the acceptance test before choosing a shape. LangGraph is that rule's canonical counterexample.

Is anything LangGraph-shaped still on the machine?

In the package code: zero imports, two comment tombstones, and the graph directory gone. In the venv: the pip package still sits there, unimported — deleted code, undisturbed dependency. The 203-line engine that replaced it has since grown to route three kinds of work: image, digest, and retrieval Q&A.

The LangGraph Autopsy: 12 Green Imports, 668 Silent Seconds, One 203-Line Survivor

Episode 21 of One Man One Legion — the fourth war story. Episode 20 read the failure library; this one is the fleet’s own favorite failure — the workflow framework adopted one morning and disproved within ninety minutes, told from the machine that ran it.

The bet

The orchestrator was born with a constitution: machines exchange structured work state, never chat; a workflow is a finite state machine with persistence, not a conversation. For that, LangGraph plus sqlite was the chosen shape — langgraph 1.2.11 and langgraph-checkpoint-sqlite 3.1.1 into a fresh venv — and by 12:35 on Aug 12, 2026 the work log recorded the skeleton complete: 12 modules with every import green, 9 named nodes from prompt parsing to error handling, conditional routing, a sqlite checkpointer with its tables already built.

The architectural bet, in the log’s own terms: a GPU render takes minutes, but a single execution must stay under a few seconds. So the dispatch node submits the job and hits END — the thread terminates, state parked at stage=polling — and the next scheduler tick resumes polling from the checkpoint. Long tasks segmented into short hops. On paper, exactly what the framework was for.

668 seconds

At 13:33 the same day, test T5 ran the first true end-to-end flow. Submission succeeded — the GPU box’s own history later confirmed the render finished, prompt_id 6f476a70; a picture existed. The orchestrator sat in polling for 668 seconds and never advanced. The worker had done its work; the state machine never learned.

The autopsy was a minimal graph, not a debate. Two invocations of a toy entry-worker graph produced the identical call list [‘entry’,‘worker’] both times: in LangGraph, END is a thread’s terminal state, and invoking None against a finished thread is a no-op. There is no resume. The design was not buggy — it was physically impossible, and poll_comfy had never once executed after submission. The log’s verdict on the morning’s green skeleton was one word: mirage. Twelve passing imports had tested syntax, never semantics.

The deletion, and the receipt

The human picked the surgical option: keep the node functions and the database, delete the framework layer. The stated reasons mattered as much as the bug — the pipeline was nearly linear, and of all the capabilities that justified the framework (branching, human-in-the-loop, checkpointing, visualization), not one was actually in use. Capacity pre-built for a demand that never came. By 14:05 the log recorded the layer gone, along with its two orphaned checkpointer tables; the database kept its 4 business tables. In their place, a hand-rolled engine: drive() walks the stages in sequence, and the long GPU wait is an ordinary while loop — the loop absorbs the long task, so there is no resume semantic left to get wrong. Crash recovery reads facts, not snapshots: rebuild state from the task row, then re-query the renderer’s own history by prompt_id.

The receipt came at 13:59 — 26 minutes after the stall was logged — when the same flow completed in 163 seconds: submit, poll, fetch, deliver, finalize, one image back. The audit printed a poll_done line for the first time — the poll node had never run under the framework. The next morning at 11:16, a human’s Hi on Telegram got its image back in 27 seconds, confirmed by eye. From skeleton-complete to layer-deleted: 90 minutes of load-bearing life.

What the injection found

Fault injection the same afternoon — reconstructed later from a 612-event session transcript after the session was stopped before logging — turned up 4 bugs with one shared root: the fatal segmentation (already dead with the deleted layer), a stage field that stopped syncing to the database mid-run, a delivery step that incremented its sent counter without checking whether the send actually succeeded, and a poller with zero tolerance for a single transient SSH hiccup. The root, named in the log: zero tolerance — one transient failure equals death — plus false done, reporting success without checking the downstream return.

The scar hardened into rules. Two principles entered the standing constitution the next morning: import smoke is not a run, and a happy path is not validation — without fault injection, it didn’t happen. And the day after the deletion, a vector-RAG proposal flared with the identical root error, chosen because it was the standard thing before anyone asked what question it answered — which produced the form-follows-problem selection rule, with LangGraph as its canonical counterexample.

The tombstones

Read live on Aug 27: the orchestrator’s package code carries 0 langgraph imports. Exactly 2 mentions survive, both comments — one on the nodes file declaring them pure functions bound to no framework, one on the database file explaining where the checkpointer tables went. The pip package itself still sits in the venv with nothing importing it: deleted code, undisturbed dependency. And the 203-line engine now routes 3 kinds of work — image, digest, retrieval Q&A. The survivor didn’t just replace the framework; it outgrew the job the framework was hired for.

What we claim and what we don’t

All timings are as recorded in the work log for Aug 12–13, 2026, UTC by the log’s own convention. The run measurements — 668 seconds, 163 seconds, 27 seconds — are log records, not re-runs. The code counts (203 lines, 0 imports, 2 comment tombstones, 4 business tables) were read live from the orchestrator on Aug 27, 2026. Chinese log prose is paraphrased in English; only machine strings — [‘entry’,‘worker’], poll_done, END, prompt_id 6f476a70 — are carried verbatim. No ports, tokens, or chat identifiers appear.

Primary sources: ~/WORKLOG.md entries of 2026-08-12 and 2026-08-13; ~/orchestrator/engine.py, nodes.py, db.py, and venv site-packages, read 2026-08-27.

Measured 2026-08-27 from live files and the work log. License: CC BY 4.0 — cite the source URL.

Next in the war stories arc: the security handcraft — key discipline and dependency gates across the fleet, whose torch.load specimen already ran as a standalone piece. Back to the series map.