Description
When deleting a VCN that still has any gateway attached (IGW, NAT Gateway, Service Gateway, Local Peering Gateway, or DRG attachment), the error message is generic and does not identify which gateway type or OCID is the blocker.
Steps to Reproduce
- Create a VCN with multiple gateway types (IGW, NAT GW, Service GW).
- Attempt to delete the VCN without first detaching/deleting the gateways.
oci network vcn delete --vcn-id $VCN_ID --force
Expected Behaviour
The error message should identify the specific gateway type and OCID that is blocking the deletion:
message: <vcn-ocid> is associated with Service Gateway <ocid1.servicegateway...> — delete that gateway first.
Actual Behaviour
The error returned is identical for all 5 gateway types:
TransientServiceError:
code: IncorrectState
message: <vcn-ocid> is associated with Gateway that is in use
This gives no indication of which gateway is the blocker. Users must enumerate all 5 gateway types manually to discover the culprit.
Impact
In our session, we deleted the IGW and NAT GW, received a "vcn delete would now work" impression — but a Service Gateway (auto-created when the VCN was built, never manually added) was still attached. The VCN delete failed again with the same generic "Gateway that is in use" message, costing ~40 minutes of debug time.
Suggested Fix
Include the gateway type and OCID in the IncorrectState error message. OCI already has this data internally; it's just not surfaced in the error response. Even a simple enumeration like:
message: VCN <ocid> is still associated with the following gateways: [Service Gateway (ocid1.servicegateway...), NAT Gateway (ocid1.natgateway...)]. Delete or detach them first.
This would be a significant UX improvement for infrastructure teardown workflows.
Description
When deleting a VCN that still has any gateway attached (IGW, NAT Gateway, Service Gateway, Local Peering Gateway, or DRG attachment), the error message is generic and does not identify which gateway type or OCID is the blocker.
Steps to Reproduce
oci network vcn delete --vcn-id $VCN_ID --forceExpected Behaviour
The error message should identify the specific gateway type and OCID that is blocking the deletion:
Actual Behaviour
The error returned is identical for all 5 gateway types:
This gives no indication of which gateway is the blocker. Users must enumerate all 5 gateway types manually to discover the culprit.
Impact
In our session, we deleted the IGW and NAT GW, received a "vcn delete would now work" impression — but a Service Gateway (auto-created when the VCN was built, never manually added) was still attached. The VCN delete failed again with the same generic "Gateway that is in use" message, costing ~40 minutes of debug time.
Suggested Fix
Include the gateway type and OCID in the
IncorrectStateerror message. OCI already has this data internally; it's just not surfaced in the error response. Even a simple enumeration like:This would be a significant UX improvement for infrastructure teardown workflows.