アクターは、キャンセル トークン ソースでラップできるタスクをキャンセルするためにキャンセル トークンに依存します。この単一のワークフローにアクターのチェーンがある場合、キャンセル要求は、作業中のこのアクターのチェーンに伝播できます。
おそらく、各アクターの各キャンセル タスクをトークンに登録して、未完了の作業を終了する前に別の作業を実行することができます。
このシナリオでは、この一連の作業を逆の順序で終了して、最新のワーカー アクターが生成されるようにすることをお勧めします。たとえば、データベースを更新するバッチ作業を送信し、親アクターがキャンセル例外をスローする前にその作業をキャンセルすることをお勧めします。少なくとも私には、この計画は、この一連の作業の最上位にあるアクターでキャンセル例外をスローするよりも安全な方法のように思えます。
これらのキャンセルを逆の順序で登録すると（スタックを使用するなど）、最後に登録されたキャンセルデリゲートが実行され、次に2番目に最新のものとして登録されたデリゲートが実行されるようになると考えていました。
コンバイン デリゲートまたはスタックをハンドラーと共に使用することを考慮してください。正しい方向に導くために、私に知らせてください/修正してください。