WaitForDelete watches with a namespace-scoped RESTScope strategy, so a
cluster-scoped resource never receives status events and stays Unknown.
In v4.2.1, 360d4835d deferred cancellation until a real status event
arrived, which made the delete-wait on such objects block for the full
timeout; pre-install hooks with cluster-scoped resources were never
created and installs sat in pending-install (#32224). The commit was
reverted in v4.2.2 (b05881cf9), and #32261 tracks re-attempting it.
This pins the required behaviour so any re-attempt cannot reintroduce
the hang: a delete-wait over a cluster-scoped object that receives no
events must complete promptly instead of waiting out the timeout.
Verified to fail against the reverted guard and pass on main.
Signed-off-by: Bisman-Singh <bismanmadaan1@gmail.com>
t.Fatal("WaitForDelete blocked on a cluster-scoped resource that receives no status events; it must return promptly instead of waiting out the timeout")