Fix panic in aws_route53recoverycontrolconfig_safety_rule create on API error

[skymoore]

Summary

• Problem: aws_route53recoverycontrolconfig_safety_rule panics with a nil pointer dereference when CreateSafetyRule returns an error. createAssertionRule and createGatingRule assign result := output.AssertionRule / output.GatingRule before checking the error, so when output is nil the dereference crashes the provider. Through the bridge this takes down the plugin process and cascades connect: connection refused to every other in-flight resource. It is easy to hit: Route 53 ARC limits a control panel to 20 safety rules, and exceeding it returns ServiceQuotaExceededException.
• Change: Add patches/0030-Fix-panic-in-route53recoverycontrolconfig-safety_rul.patch, which moves the result assignment below the error check and the nil-response check in both functions, folding an output == nil guard into the existing nil-response check. Carries the upstream fix verbatim.
• Related issue/PR: Tracking issue Patch: fix panic in aws_route53recoverycontrolconfig_safety_rule create on API error #6577; upstream r/aws_route53recoverycontrolconfig_safety_rule: fix panic on CreateSafetyRule error hashicorp/terraform-provider-aws#49155 (fix) and r/aws_route53recoverycontrolconfig_safety_rule: panic on CreateSafetyRule error (nil pointer dereference) hashicorp/terraform-provider-aws#49154 (bug).

This PR is intentionally opened as a draft pending maintainer guidance on the required regression coverage and CI selection (see the open items below).

Change Type

• Provider logic only (provider/)
• Schema or mapping change (may require SDK regeneration)
• Upstream or patch pipeline change (upstream/, patches/, scripts/upstream.sh)
• CI workflow source change (.ci-mgmt.yaml)

Carried Upstream Patch

• Patch tracking issue created: Patch: fix panic in aws_route53recoverycontrolconfig_safety_rule create on API error #6577
• Owning-project issue or pull request linked: r/aws_route53recoverycontrolconfig_safety_rule: fix panic on CreateSafetyRule error hashicorp/terraform-provider-aws#49155
• Differences from the owning-project change explained: none, the patch carries the upstream change verbatim.
• Compatibility and removal risks documented: see tracking issue. No schema, public API, state, or migration surface. Removal is safe once an upstream release containing #49155 is vendored.
• Required upstream acceptance test added: not added. The route53recoverycontrolconfig package has no unit-test harness for the create path, and its acceptance tests exercise live safety rules against the 20-per-control-panel limit. Asserting the panic-to-diagnostic behavior needs an account with an already-full control panel. Requesting guidance on whether a live test is warranted for a statement-reorder crash fix.
• Test selected in .github/workflows/aws-upstream-tests.yml: pending the decision above.
• Pulumi regression test added: not added, pending guidance. A focused regression would require a control panel at its safety-rule limit to force the error path.
• Provider-upgrade coverage added, if required: not required (no schema, diff, or state change).

Validation Evidence

The patch applies cleanly against the pinned upstream submodule, and the fix was verified end to end against live AWS through the bridge (pulumi-aws 7.39.0 with this patch built into the provider binary). Before the patch, creating a safety rule on a full control panel crashed with SIGSEGV. After the patch, the same operation returned the underlying diagnostic:

creating Route53 Recovery Control Config Assertion Rule: operation error Route53 Recovery Control Config: CreateSafetyRule, https response error StatusCode: 402, api error ServiceQuotaExceededException: <control-panel-id> cannot have more than 20 SafetyRules. Current number of Safety Rules is 21

I have not run make test_provider or make lint in this branch: the change is a patch file only, with no provider/ Go changes, and the underlying reorder is validated upstream in hashicorp/terraform-provider-aws#49155. I will run any repository-specific validation the maintainers require before this leaves draft.

Command output snippets

$ git -C upstream apply --check patches/0030-Fix-panic-in-route53recoverycontrolconfig-safety_rul.patch
(exit 0, applies cleanly)

$ go build ./internal/service/route53recoverycontrolconfig/   # in upstream, with patch applied
(build succeeds)

Risk

• Blast radius: two functions in internal/service/route53recoverycontrolconfig/safety_rule.go. No success-path behavior change; only the previously unreachable error path changes from panic to a returned diagnostic.
• Edge cases: covers both assertion and gating rules, and both the output == nil and non-nil-but-empty response shapes.

Rollback

• Revert plan: delete patches/0030-*.patch and rerun the patch pipeline.
• Follow-up cleanup: remove the patch once an upstream release with #49155 is vendored into the submodule; close Patch: fix panic in aws_route53recoverycontrolconfig_safety_rule create on API error #6577 at that time.

---

AI assistance disclosure: I used an AI coding assistant to help trace the panic to the faulty statement ordering, draft the patch header, and draft this description. I own and reviewed the change; it is a statement reorder in two functions and I understand its behavior and removal conditions.

[github-actions]

PR is now waiting for a maintainer to run the acceptance tests.
Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR