A failure in the final cell can make the whole notebook look as if nothing happened. Earlier cells may already have created material or sent an operation. I retained their outputs alongside the error instead of keeping only its final message, so later diagnosis can examine what actually remains before deciding what may be repeated.
Avoid saving only after success
The library notebook runner wraps execution in a try block and writes the executed document in finally. It does not save only at the end of a successful path. An exception can therefore leave earlier output and the error cell available for inspection, with the success message occurring after the write path.
A finally block cannot guarantee that storage succeeds. Disk or destination errors can still prevent writing. Actual file retention needs another check. Handling an execution exception and successfully retaining the execution document are distinct results; the explanation should not exchange one for the other.
Bind each output to its executing cell
The kernel filters replies by the execution request's parent message identity, and the host accepts output for the current executing cell identity. Starting a cell clears that cell's output rather than discarding all earlier outputs. An error stops further cells and enters the saved error state.
Late output must not be attached to an unrelated current cell merely because text arrived. Ownership matters before presence. The visible division into cells needs a matching execution-message boundary for people to trust the failure location. Numbered boxes alone would not establish which operation produced the information being shown.
Distinguish quiet execution from a failed kernel
When output is temporarily absent, execute checks whether the kernel process is alive and continues waiting. Quiet computation does not become success or failure merely because it has no recent text. A dead kernel instead raises an error so the host need not remain busy forever. Completion comes from the matching execution's idle message.
The existing unit test extracts the actual execute function and supplies message and liveness stubs. That differs from launching the full IPython environment. It establishes the function's waiting and dead-process decisions, not fresh field verification of every long-running calculation.
Retained output is not a complete raw log
Internal display and import paths limit text length, image size, output count and overall retained volume. Large output is not guaranteed to survive in full. Imported notebook HTML is not executed as a display capability; supported text and PNG material follow their defined paths.
Those choices keep the interface and stored document manageable while allowing diagnostic information to be partial. A truncated final value or separately retained artifact can require additional inspection. Storage does not create a complete forensic log. Displayed output and examination of the actual resulting file remain different kinds of evidence.
Neither the item journal nor output replaces the other
A success sentence in notebook output still needs the item journal's state checked. A retained run identity still needs the error-cell context and actual artifacts inspected. Output helps explain calculation and exceptions, while the journal manages the item's execution lifetime.
The shared journal module independently implements only a small state-recording part. Its twenty-four tests and extracted-package checks do not make it a notebook-output collector. This article also runs no original application cells. Code and existing evidence support separate claims about each retained source rather than one undifferentiated assertion of recovery.
After an error, provide a reading path before another execution
If results can be inspected only by rerunning every cell, diagnosis itself can redeliver business actions. Result cells and retained documents should remain separately readable after failure. Earlier success beside the final error helps narrow what needs attention next.
Business batch processing has the same property: one failed item does not erase documents already created or material already delivered. Error evidence is useful operating material rather than an unwanted byproduct. Retaining earlier output lets continuation begin with established facts instead of hiding failure behind a full restart.