VCN delete reports connection timeout but operation actually succeeds in the background

[surapuramakhil]

Description

oci network vcn delete intermittently returns a RequestException: The connection to endpoint timed out error, but the actual delete operation succeeds in the background. Naive retries then succeed immediately with "already deleted" rather than failing. This makes the timeout error misleading — it reports a failure when the operation actually completed.

Steps to Reproduce

1. Create a VCN with no attached gateways.
2. Delete the VCN:

oci network vcn delete --vcn-id $VCN_ID --force

3. Observe intermittent timeout errors:

RequestException: The connection to endpoint timed out.

4. Retry the same command:

oci network vcn delete --vcn-id $VCN_ID --force
# Succeeds immediately (resource already deleted)

Expected Behaviour

The CLI should distinguish between:

1. Request timed out (the operation may have succeeded) — suggest the user verify state before retrying.
2. Operation failed (the API returned an error) — the delete did not happen.

A clear message like:

Request timed out. The delete operation may have completed in the background.
Verify with: oci network vcn get --vcn-id $VCN_ID

Actual Behaviour

The error message The connection to endpoint timed out is identical to a real failure, leading users to:

1. Retry naively (which succeeds immediately, wasting time on unnecessary retries).
2. Or worse, assume the delete failed and take incorrect remediation steps.

Impact

During a large infrastructure teardown session, we saw this timeout repeatedly on vcn delete commands. Each time, the delete actually succeeded but we had to verify manually, adding unnecessary friction to the workflow.

Suggested Fix

1. Distinguish "request timed out" from "operation failed" in the error output.
2. When a timeout occurs on a delete/update operation, include guidance to verify state before retrying: "The request timed out. The operation may have completed. Verify with 'oci <resource> get' before retrying."
3. Consider implementing a short post-timeout verification check (e.g., poll the resource state once after timeout) to give a definitive answer.