Skip to content

Read the status before pressing again, and report what EC actually said - #99

Merged
amrali-eg merged 1 commit into
masterfrom
fix/cancellation-status-reporting
Sep 9, 2026
Merged

Read the status before pressing again, and report what EC actually said#99
amrali-eg merged 1 commit into
masterfrom
fix/cancellation-status-reporting

Conversation

@amrali-eg

Copy link
Copy Markdown
Owner

Three findings from reviewing the cancellation state machine merged in #97, in
the order they matter. No production code changes; MainForm was read and
not edited. Rebased onto the #98 merge and revalidated as a combination.

1. A refused press could starve the status check

The press sat above the status read, and a refusal throws out of the press - so
on a refusing iteration the status was never examined. Progress depended on the
button disappearing rather than on the run reporting.

The status is now read first. With a button that stays visible and refuses, the
previous order runs the full thirty seconds and then claims no Cancel button
appeared, while the button was present throughout and the run had already
reported; reading first, the same conditions classify correctly.

2. A failed conversion was reported as a cancellation problem

Any final status other than Conversion stopped produced "Cancellation was not
exercised", including Conversion failed., which MainForm writes when a
genuine error occurs mid-run. That reports a real EC defect as an instrument
timing problem, in the phase whose purpose is checking EC's reporting.

Three outcomes now get three answers: Conversion stopped passes, Conversion complete says the run finished before it could be stopped, and anything else
says the run neither stopped nor completed and this phase proved nothing about
cancellation.

3. Two messages claimed more than they knew

pressed was set for a press whose delivery is unknown as well as one that
succeeded, and the timeout said "Cancel was pressed" - which the next clause
retracted. It is now pressAttempted, and says a press was attempted.

The other branch said "No Cancel button appeared"; it now says the driver could
not find one. Automation failing to see a control is not evidence about the
control.

Evidence

Control Corrected Previous
Button always present, always refusing Classifies from the status 30s timeout, then claims no button appeared
EC reports Conversion failed. "neither stopped nor completed... proved nothing about cancellation" "Cancellation was not exercised"
Press lands, no final status "A Cancel press was attempted..." "Cancel was pressed..."
Full suite, after rebase 8/8
Unit tests 756 passed

Mutations required a successful build before running, with the source restored
byte-for-byte afterwards.

EC-28 remains open: none of this explains the phase A
failure that opened it.

🤖 Generated with Claude Code

Three findings against the cancellation state machine, in the order they matter.

The status is now read before a press is attempted. A refusal throws out of the
press, so attempting first meant the status was never examined on a refusing
iteration: progress depended on the button disappearing rather than on the run
reporting. With a button that stays visible and refuses, the previous order runs
the full thirty seconds and then claims no Cancel button appeared - while the
button was present throughout and the run had already reported. Reading first,
the same conditions classify correctly.

A conversion that failed is no longer called a cancellation problem. Three
outcomes now get three answers: "Conversion stopped" passes, "Conversion
complete" says the run finished before it could be stopped, and anything else -
"Conversion failed." among them - says the run neither stopped nor completed and
this phase proved nothing about cancellation. Reporting EC's own failure as an
instrument timing problem would hide a real defect in the phase that exists to
check EC's reporting.

pressed becomes pressAttempted, and its timeout says "A Cancel press was
attempted", because it is set for a press whose delivery is unknown as well as
one that succeeded. The old wording asserted a delivery the next clause retracted.

For the same reason the other branch of that timeout now says the driver could
not find a Cancel button, rather than that none appeared: automation failing to
see a control is not evidence about the control.

Controls, each against the previous shape for comparison: a button that always
refuses now classifies from the status instead of timing out; a reported
"Conversion failed." produces the neither-stopped-nor-completed message instead
of "Cancellation was not exercised"; and a landed press with no final status
reports an attempt.

EC is unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@amrali-eg
amrali-eg merged commit 28dc1c1 into master Sep 9, 2026
3 checks passed
@amrali-eg
amrali-eg deleted the fix/cancellation-status-reporting branch September 9, 2026 23:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant