Improved error / fail sooner when pool removal is gated with a delete lock
We recently had a case where a pool removal was 'stuck' and it appeared that the completion of the command was gated by the timeout value (which we inadvertently made very long).
It turned out that the removal of the pool needed to delete a configuration on a subnet which was part of a VNet/RG that had a deletelock applied.
It seems unreasonable to hang a process for a configuration change and would propose that in this case the resize should've failed once it determined it was blocked due to a delete lock on a 'sub resource'. Even better if it could indicate the pool removal failed due to the lock.
The batch account itself had NO delete locks applied.