Test a long job by interrupting it

A long task is easy to describe while it is running normally. The more revealing moment comes after the process disappears. Which files were saved? Which tests finished? Did the last external action happen before the connection dropped? A restart procedure needs answers that survive the lost session.

My February 2026 integration reports included crashes on larger jobs. They did not establish the cause or a stable repair. The later Boris specification, written for an agent interface with long mixed tasks, called for durable checkpoints, action records, and recovery from observed resource state. Those requirements describe a design to test; the recovered specification is not evidence that the whole design was implemented.

An interruption test should start with a bounded job in a disposable workspace. Give the job several observable stages, including one saved artifact and one verification step. Decide in advance which data may be discarded, which work must survive, and which action cannot safely be repeated without inspection.

An illustrative document job

Suppose an assistant converts twenty source notes into a draft handbook. It extracts the notes, creates sections, assembles the document, renders it, and checks the rendered pages. Interrupt the process after the document is saved but before the rendering result is recorded. This is an illustrative exercise, not a reported Boris run.

On restart, the assistant should find the saved document and its recorded identity, then inspect whether the rendering process is still active and whether any existing output belongs to that document, retaining the observations that justify either waiting for the process or examining its result. A filename alone cannot settle the last question if an older render occupies the same directory.

If the current render is complete, the workflow can verify and register it. If rendering never started, it can start the authorized operation. If the state remains ambiguous, record that ambiguity and inspect further before creating another process. The checkpoint gives the assistant a starting account, while the files and running processes establish what actually happened after it was written.

Choose checkpoints around material changes

Saving state after every token would produce extensive records with little recovery value. Saving only at the end leaves the entire job vulnerable. Useful checkpoints follow material tool results, artifact saves, approvals, and changes in phase status. Each should identify the contract version and the inputs whose results it preserves.

Checkpoint writes can fail too. Test interruption during the write, retain a previous valid checkpoint, and detect incomplete records when loading them. If a workflow changes its state format between releases, define how older records migrate and preserve the original until migration succeeds, since an ordinary software update can otherwise leave a saved task unreadable even though its artifacts and unfinished work still exist.

The test should also include user takeover. Stop desktop actions when the user changes the active application, release held input, and obtain a fresh observation before resuming. Coordinates from the earlier screen may now point at a different control. A saved intention to click something does not establish that the target is still present.

Measure recovery separately from completion

Record what was lost, what was repeated, and what evidence permitted each resumed step. Count duplicate artifacts or external effects. Measure the time spent reconstructing state separately from the remaining task duration. These observations reveal whether recovery helps or merely restarts the whole job under a different session identifier.

Repeat the interruption at several boundaries, including a stop before dispatch and one after the target application accepts the request, then compare those records with interruptions during artifact creation and verification to establish which recovery decisions require different evidence. Vary the boundary deliberately and retain the resulting records, rather than treating a single successful restart as coverage of every failure mode.

Budget limits belong in this test. A workflow that can resume indefinitely may also repeat an unproductive repair indefinitely. Define repeated-failure thresholds and retain the unchanged inputs that triggered them. When the allowed attempts are exhausted, the saved record should identify the specific dependency or decision needed to continue.

For the handbook exercise, acceptance means reopening the current document, confirming that its required sections exist, and checking a render tied to that document’s identity. The final report should identify any discarded partial output and any work repeated after restart. Run the exercise again at a different interruption boundary before extending the recovery claim to the rest of the workflow.

Source notes

Draws on my reported integration crashes and the September 2026 Boris recovery specification. The document job is an illustrative acceptance exercise, not a completed runtime demonstration.