Scenario 02: Stop Versus Abort

Why This Scenario Matters

Many newcomers understand cancellation in theory but still blur together graceful stop and immediate abort. Industrial and machine-adjacent systems cannot afford that confusion.

This scenario teaches one of the most important runtime distinctions in the repo:

• Stop is cooperative and tries to finish at a safe boundary
• Abort is immediate and cancels in-flight work

This is a direct exercise of the workflow semantics documented in SLICE-001.

Operator Actions

Part A: Graceful Stop

1. Connect to the machine.
2. Load a recipe with multiple scan points, ideally standard-5pt-wafer-scan.
3. Home the stage.
4. Start a run.
5. Wait until the run is clearly active and at least one scan point has started.
6. Click Stop.
7. Keep watching the progress and diagnostics until the run reaches a terminal state.

Part B: Immediate Abort

1. Prepare another run with the same or a similar recipe.
2. Start the run again.
3. Click Abort while work is still active.
4. Watch how much less work continues after the request.

Expected UI And State Changes

Stop Behavior

After clicking Stop, you should see:

• the workflow move to Stopping
• a diagnostics message explaining that the current safe step will complete
• no new scan point begin after the stop request is accepted
• a terminal workflow state of Stopped
• a run summary whose terminal status is Stopped

The important operational detail is that the machine does not pretend the stop never happened, but it also does not cut work at an arbitrary unsafe moment.

Abort Behavior

After clicking Abort, you should see:

• diagnostics indicating immediate cancellation
• the active work stop much more abruptly
• a terminal workflow state of Aborted
• a run summary whose terminal status is Aborted

Compared with Stop, Abort should feel harsher and faster.

What To Notice

Watch these differences carefully:

• whether the current point finishes before terminal state
• whether the workflow passes through Stopping
• whether additional progress increments happen after the request
• how the diagnostics wording differs
• how the final run history row differs between Stopped and Aborted

This scenario is less about the buttons and more about the operational contract behind them.

What To Inspect In Code After Running It

Start with:

• src/InspectionPrototype.Application/Services/WorkflowService.cs
• src/InspectionPrototype.Application/Guards/CommandGuards.cs
• src/InspectionPrototype.Application/State/WorkflowState.cs

Look specifically for:

• RequestStop() and how it sets WorkflowState.Stopping
• AbortAsync() and how it cancels in-flight work
• the run loop checks that prevent a new scan point from beginning after stop
• the terminal status mapping from internal termination reason to Stopped or Aborted

This is also a good moment to inspect the test suite around workflow termination behavior.

Troubleshooting Notes

• If Stop appears to do nothing, wait for the current safe step to finish before judging the result.
• If you click Abort after the run has effectively finished, the request may be rejected because the workflow is already terminal.
• If neither command is enabled, verify that the workflow is currently Preparing, Running, or Stopping according to the guard rules.

Related Lessons And Specs

• SLICE-001: First Strong Vertical Slice
• 20. Advanced Async Coordination
• 04. CancellationToken in Production - Real World
• 07. Sequencing in Industrial Machines
• 05. Machine States Lifecycle Overview

Diagram Brief

• Title: Stop versus abort runtime behavior
• Purpose: Contrast graceful stop with immediate abort during an active run
• Audience: newcomer engineer learning cancellation semantics in industrial software
• Nodes: Operator, MainViewModel, WorkflowService, RunLoop, MotionController, CameraController, AppStateStore
• Edges: stop request transitions to stopping and lets the current safe step end; abort request cancels current work and moves directly toward terminal abort
• Groups: Stop path, Abort path
• Caption: Stop preserves safe-step semantics; abort prioritizes immediate interruption
• Destination file path: docs/diagrams/source/scenario-02-stop-vs-abort.drawio