74fc891350
A container that schedules a child and then decides the child must not run had no way to withdraw it. `IActivityScheduler` exposed no removal operation, and `CancelActivityAsync` no-opped on a context whose status was `Pending`, so a container could tear a branch down and still have an activity from that branch execute afterwards, side effects and all. Fixes #7943. - `IActivityScheduler.RemoveWhere` removes work items and keeps the order the survivors would have been taken in; implemented in both the FIFO and LIFO schedulers. - `CancelActivityAsync` (both the public extension and the internal one used when a container completes) cancels `Pending` contexts as well as running ones, and withdraws the work item that would have started the cancelled activity plus the items it had scheduled for children with no context yet. Withdrawal is a real removal rather than a terminal status honoured at dequeue time, because the scheduler is also read: `Flowchart.HasPendingWork` inspects it to decide whether it may complete, and the work item list is extracted into the persisted workflow state — a withdrawn-but-queued item would be persisted and rehydrated with a fresh context after a suspend/resume. `StateMachine` had hand-rolled the same operation to drop competing triggers by clearing the scheduler and re-scheduling everything else; it now calls `RemoveWhere`. `Elsa.Bpmn` no longer needs to refuse a teardown whose subtree still has queued work, so `BpmnWorkTeardown` drops the `NotSupportedException` and records the teardown reason on the torn-down activity's journal instead. BREAKING: `IActivityScheduler` gains a member; external implementations must add `RemoveWhere`. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| adr | ||
| agent-logs | ||
| bounty | ||
| changelogs | ||
| qa | ||
| security-assessment | ||
| website | ||
| wiki | ||