mirror of
https://github.com/rmcrackan/Libation.git
synced 2026-09-12 21:57:19 -04:00
Allamagoosa
492d2e9ae3
The gate read a queue-wide cancelAllRequested flag, which then had to be cleared again - and whatever clears it can un-cancel a book that is still parked. Clearing it at the end of the cancellation drain was the window you described; scoping it to the run moved that window into AddToQueue, which cleared it so newly queued books would not inherit an old cancellation. Same bug, different trigger. WaitForDailyLimitAsync already waits on behalf of one specific book, so it now asks whether that book was cancelled. Cancel All reaches a parked book through ProcessBookViewModel.CancelAsync like any other active book - it is on the active list, having been dequeued before the gate - so nothing has to be set or cleared at the queue level and the flag is gone entirely, along with both of its clear sites. Books queued afterwards are untouched by construction rather than by timing. CancelAsync records the request before its early return, because a book that has not started a step is precisely the case that matters. That also makes cancelling a single parked book work, which it previously did not.