{"version":"2.1.265","anchor":"abort-handling-reordered-ahead-of-the-process-committed-gu","canonical_anchor":"abort-handling-reordered-ahead-of-the-process-committed-gu","heading":"Abort handling reordered ahead of the 'process committed' guard","tier":"internal","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/abort-handling-reordered-ahead-of-the-process-committed-gu","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Abort handling reordered ahead of the 'process committed' guard\n\nAbort-signal checks in tool-permission requests now run before the 'never resolves' hang guard, not only inside it\n\n**What**\n\nIn the code paths that send tool-permission requests and control requests, checking whether the operation has been aborted now happens unconditionally and first. Previously, the guard that intentionally hangs forever (by returning a promise that never resolves) when the process is already committed only ran inside a conditional block; now that hang guard runs after the abort check, rather than being nested inside it.\n\n**Why**\n\nReordering these checks means an abort is more reliably noticed before the code can get stuck in the intentional 'hang forever' branch, which should reduce cases where a permission or control request appears to freeze instead of properly cancelling.\n\n- Area: Permissions\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}