fix(flow): reset cancellation flag at the start of each execution

[XuQuanxin04]

Summary

LightFlow.cancel() sets self._cancelled = True, but that flag was only read in _execute() and never reset. Because run(), resume(), and rerun_step() all go through the same _execute() path on a reusable LightFlow instance, a single cancel() call permanently poisoned the instance — every subsequent run skipped all of its steps with "cancelled before execution", even when cancellation was requested after a run had already finished.

Reproduction

flow = LightFlow().step("a", agent=agent_a).step("b", agent=agent_b, depends_on=["a"])
flow.run("one")          # works: a, b succeed
flow.cancel()            # user cancels after run 1 completes
flow.run("two")          # BUG: both a and b are skipped; agent.run() never called

Fix

Reset self._cancelled = False at the start of _execute(). In-flight cancellation is unaffected — the flag is still re-checked before every step, so a cancel() from another thread during a run still skips the remaining steps of that run.

Compatibility

• Existing agent.run("hello") behavior is unchanged.
• Existing stream=True behavior is unchanged.
• In-flight cancel() behavior is preserved (added a test for it).

Tests

• python -m compileall -q LightAgent
• PYTHONPATH=. python -m pytest -q tests/test_v065_core.py tests/test_v070_tracing.py tests/test_memory_policy.py — 57 passed
• Added two tests to tests/test_lightflow.py:
  • test_lightflow_cancel_during_run_skips_remaining_steps_of_that_run — guards the existing in-flight cancel behavior.
  • test_lightflow_cancel_between_runs_does_not_poison_the_next_run — regression test for this bug.
• Full tests/test_lightflow.py: 16 passed.

[wxai-space]

Changes requested

The underlying bug is valid, but resetting self._cancelled = False at the start of _execute() introduces a cancellation race.

If run() has been called but has not entered _execute() yet, a concurrent cancel() can set the flag and _execute() immediately clears it. The run then executes successfully instead of honoring the cancellation request.

Please replace the shared sticky boolean with an execution-scoped cancellation token or generation captured when run(), resume(), or rerun_step() starts. The token should be checked before each step, and cancellation after an execution has completed should be a no-op for the next run.

Please add a deterministic regression test covering cancellation between invocation of run() and entry into _execute(), plus a test documenting behavior for concurrent executions.

[XuQuanxin04]

Thanks for the review. I replaced the sticky shared boolean with execution-scoped cancellation events registered before run(), resume(), or rerun_step() enters _execute().

cancel() now snapshots and cancels every currently active execution. Calling it after all executions have completed is a no-op for future runs. Each execution checks its own event before every step, and registration is removed in finally paths.

Added deterministic coverage for:

• cancellation after run() is invoked but before base _execute() begins;
• cancellation during a run;
• cancellation after a completed run not affecting the next run;
• two concurrent executions on one flow (documented behavior: cancel() cancels both active executions).

The public behavior and the recommendation to use separate LightFlow instances for independently cancellable concurrent runs are documented in docs/lightflow.md.

Validation: 265 passed, 1 skipped; repository-required focused suite included; compileall and git diff --check passed.

Updated in 288d692.

[XuQuanxin04]

Addressed in commit 288d692: cancellation is now execution-scoped, covers the pre-_execute race and concurrent executions, and is documented. Full suite: 265 passed, 1 skipped. I also posted the detailed validation on PR #97. At 2026-09-04 16:21:29, "weego" ***@***.***> wrote: @wxai-space requested changes on this pull request. Changes requested The underlying bug is valid, but resetting self._cancelled = False at the start of _execute() introduces a cancellation race. If run() has been called but has not entered _execute() yet, a concurrent cancel() can set the flag and _execute() immediately clears it. The run then executes successfully instead of honoring the cancellation request. Please replace the shared sticky boolean with an execution-scoped cancellation token or generation captured when run(), resume(), or rerun_step() starts. The token should be checked before each step, and cancellation after an execution has completed should be a no-op for the next run. Please add a deterministic regression test covering cancellation between invocation of run() and entry into _execute(), plus a test documenting behavior for concurrent executions. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>