[Internal Range] Fix for issue #27175

[dorianverna]

Release Note Template for Downstream PRs (will be copied)

See Write release notes for guidance.

Issue: hashicorp/terraform-provider-google#27175

Summary of Changes & Solutions

This PR replaces the previous reverted implementation (#17431) with a safer solution.

Please see the following matters:

1. Safer GKE Cluster Protections

Strictly enforcing that the subnetwork empty PATCH is sent when the user explicitly sets the virtual flag send_secondary_ip_range_if_empty = true, this way GKE-managed ranges (which do not set this flag) are now completely safe from unintended capacity deletions.

2. Bug 1: Detaching/Deleting InternalRange (#27175)

• The Problem: Terraform attempts to delete the google_network_connectivity_internal_range resource while the subnetwork still has it registered in GCP, resulting in a 400 Resource already being used failure.
• The Structural Safe Fix:
  • I implemented a retry loop (internal_range_retry.go.tmpl) in InternalRange deletion. It intercepts GCE's 400 "already being used" error and retries, allowing GCE's eventual-consistency detachment to propagate.
• The Terraform Core Graph Lock Fix:
  • During testing, I discovered a silent graph optimization bug in Terraform core: it completely discards/skips the subnet update (to remove a range) if the VM using it and the InternalRange itself are planned for deletion in the exact same step.
  • I bypassed this core limitation by restructuring the targeted acceptance test this way:
    1. Delete the VM to release GCE's active IP range lock.
    2. Remove secondary_ip_range blocks from HCL, keep the InternalRange block in HCL to preserve the active depends_on edge. This forces Terraform core to successfully execute the subnet Update PATCH.
    3. Delete the InternalRange block from HCL. Since the subnet released it in Step 4, deletion is successful.

3. Bug 2: Positional Stability & Index-Based Reordering

• The Problem: Adding a new secondary range that sorts lexicographically before an existing range (or re-adding a range) triggers a positional shift diff in the TypeList schema, showing a "rename" at position 0 instead of a clean addition. In real-world in-use subnets, this positional re-ordering fails to apply.
• The Solution:
  • I removed the reverted unordered_list: true breaking change (which broke schema structures and GKE clusters).
  • I replaced it with resourceComputeSubnetworkSecondaryIpRangeSetStyleDiff index alignment function in the subnetwork constants templates. It maps surviving/existing ranges to their original index slots, preventing positional shifts and schema breakage.

compute: fixed an issue in `google_compute_subnetwork` where `secondary_ip_range` entries linked to an `internal_range` could not be removed and adding new ranges would sometimes fail due to positional shifts ([#27175](https://github.com/hashicorp/terraform-provider-google/issues/27175))

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit 63760d2:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	5 files changed, 556 insertions(+), 306 deletions(-)
google-beta provider	View Diff	5 files changed, 565 insertions(+), 306 deletions(-)
terraform-google-conversion	View Diff	4 files changed, 359 insertions(+), 18 deletions(-)

Test report

Analytics

Total Tests	Passed	Skipped	Affected
1472	1376	93	3

Affected Service Packages

• compute
• networkconnectivityv1

Learn how VCR tests work

---

Step 1: Replaying Mode

Action taken

Found 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit.

Click here to see the affected tests

• TestAccComputeSubnetwork_secondaryIpRangeInternalRangeInUse
• TestAccComputeSubnetwork_secondaryIpRanges
• TestAccComputeSubnetwork_secondaryIpv6Ranges

View the replaying VCR build log

---

Step 2: Recording Mode

Recording Mode	Replaying Rerun	Test Name
✅ Log	✅	TestAccComputeSubnetwork_secondaryIpRangeInternalRangeInUse
✅ Log	✅	TestAccComputeSubnetwork_secondaryIpRanges
✅ Log	✅	TestAccComputeSubnetwork_secondaryIpv6Ranges

🟢 All tests passed!

View the recording VCR build log or the debug logs folder for detailed results.

@dorianverna VCR tests complete for 63760d2!

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit 0e8230f:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	5 files changed, 556 insertions(+), 306 deletions(-)
google-beta provider	View Diff	5 files changed, 565 insertions(+), 306 deletions(-)
terraform-google-conversion	View Diff	4 files changed, 359 insertions(+), 18 deletions(-)

Test report

Analytics

Total Tests	Passed	Skipped	Affected
1472	1379	93	0

Affected Service Packages

• compute
• networkconnectivityv1

Learn how VCR tests work

---

Step 1: Replaying Mode

🟢 All tests passed in Replaying mode! No Recording was needed.

View the replaying VCR build log

@dorianverna VCR tests complete for 0e8230f!

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit e6ae463:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	5 files changed, 556 insertions(+), 306 deletions(-)
google-beta provider	View Diff	5 files changed, 565 insertions(+), 306 deletions(-)
terraform-google-conversion	View Diff	4 files changed, 359 insertions(+), 18 deletions(-)

Test report

Analytics

Total Tests	Passed	Skipped	Affected
1472	1379	93	0

Affected Service Packages

• compute
• networkconnectivityv1

Learn how VCR tests work

---

Step 1: Replaying Mode

🟢 All tests passed in Replaying mode! No Recording was needed.

View the replaying VCR build log

@dorianverna VCR tests complete for e6ae463!

[github-actions]

Googlers: For automatic test runs see go/terraform-auto-test-runs.

@NickElliot, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[dorianverna]

Hi @SirGitsalot, since we detected a culprit with the last PR trying to solve these issues, can you please take a look at this PR as well? #17431

Thanks a lot!

[github-actions]

@rileykarson This PR has been waiting for review for 3 weekdays. Please take a look! Use the label disable-review-reminders to disable these notifications.

[rileykarson]

@modular-magician reassign-reviewer

[melinath]

@modular-magician reassign-reviewer @NickElliot

reassigning to Nick as the original reviewer.

[melinath]

Revert PR #17698 discusses the reasons for revert.

[github-actions]

@NickElliot This PR has been waiting for review for 3 weekdays. Please take a look! Use the label disable-review-reminders to disable these notifications.

[NickElliot]

tests the original fix was causing to fail passed in a manual teamcity run, the described fix as implemented should be fully covering the problematic situation. LGTM