VpcDeletionVerdict

Whether a DELETE would be accepted right now, from the census and the VPC's status alone — it says nothing about the caller's permission, and the DELETE re-evaluates it under lock, so a concurrent write can still turn a true into a 409. False with every blocker and in-flight count at zero means the status is what refuses: a job owns the row.

What the reader can act on NOW: ready rows, parked teardowns to retry, and failed rows still holding provider objects — and a VPN connection in any provider-reported state or in failed, refs or none. The DELETE's 409 returns this same object under error.details.blockers.

What the reader must WAIT for: a create, acquire or delete job owns the row. These refuse the DELETE too, under their own key, so the checklist can say "wait" rather than "delete"; the 409 returns them under error.details.inFlight.

What GOES WITH the delete and needs nothing from the reader: rows that never reached the provider, plus the VPC's own default security group — never a VPN connection. The delete job soft-deletes them.