An operator can stop while the Python environment is still being prepared. If the request is discarded because no process exists yet, the completed preparation can later launch unwanted work. I treated startup as cancellable work and rechecked cancellation at the execution boundaries after waiting.

A stop request is more than a command to an existing process

Shutdown records cancellation first. If no kernel exists, it checks whether there is completion to await and returns. Absence of a process handle does not erase the intention to stop. A startup path still preparing work must be able to observe that retained state later.

A deliberately new run resets cancellation at the beginning of its own lifetime. The design is not meant to prohibit all future work forever. A new human intention and a late return from old preparation are different events. Even a boolean flag needs an explanation of which execution is allowed to reset it.

Check again after environment preparation and before spawn

Startup checks cancellation after prior-kernel cleanup, after loading the document and awaiting the interpreter, after preparing runtime files, and after the local server begins listening. Human intent can change during any awaited preparation.

A check only at function entry misses a later stop. Discovering cancellation only after creating the child has already started unnecessary work and cleanup. Successful asynchronous preparation is not execution permission. The prepared dependency and the continuing intention to use it are distinct conditions that must meet again at the launch boundary.

Preparation belongs to busy state before a kernel exists

Run sets its operating flag before loading the notebook, preventing another run while the kernel is not yet created. Initial load failure clears it, and execution cleanup settles completion and screen changes. Process presence alone does not describe the full startup state.

A busy flag is not proof against every shutdown race. The relevant await and its possible later effects must be examined. No-later-process matters alongside the visible idle result. An apparently quiet interface with delayed work still able to launch would not constitute settled cancellation.

Hold the exact awaited boundary in the test

The existing test inserts a gate into interpreter preparation, requests shutdown while held, then releases preparation. Its interpreter name is a sentinel that must never spawn. It requires idle state, a retained stop message and no kernel. A second test delays the initial notebook load in the same way.

That makes the ordering explicit instead of hoping a timing-sensitive race happens by chance. The tests cover those preparation and document-load boundaries. They do not exhaust every readiness race after child creation or every operating system. Precise small evidence is more useful than a broader unsupported claim of cancellation coverage.

Cancelling preparation differs from reconciling an external action

These scenarios prevent an execution that should not begin. They do not undo a mutation already delivered through the browser. Work needing a durable journal and preparation cancelled before launch are different cases. An unresolved external outcome still needs to be inspected before another operation.

This content task reruns no original test and terminates no user kernel. It reads the functions and existing gated tests to explain the maker decision. The shared file journal has separate save and reopen evidence. Distinguishing work that never began from work already delivered makes cancellation limits understandable.

A late successful dependency cannot override present intent

Environment preparation and file reading can succeed after the operator has stopped. Their success must not force another execution. Rechecking current conditions when asynchronous work returns is a useful discipline even in a small program.

Business applications encounter the same pattern when someone closes a view or changes a destination during loading. Late material should not be applied under an obsolete intention. Careful startup and cancellation handling is less about accumulating exception messages than establishing which current work, if any, still owns the late result.