Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
PermissionsArea: what it touches
Internal ChangesKind: in v2.1.265,
Internal ChangesSection of the release
What
In 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.
Why
Reordering 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.
