Workaround upstream bug: aws_route53domains_delegation_signer_record dropped from state on refresh - #6524
Open
smithrobs wants to merge 1 commit into
Open
Conversation
…fresh bug Adds a new upstream patch (0028) that fixes the resource being dropped from state (and force-recreated) on every refresh, reported upstream at hashicorp/terraform-provider-aws#47928. The bug: Create stored the DnssecKey.Id returned by AssociateDelegationSignerToDomain, but GetDomainDetail (used by Read) does not reliably echo that value back, so Read's lookup by Id always failed, causing Terraform to remove the resource from state on refresh and then try to recreate it (which fails because the DS record already exists in the registry). The patch keys Create/Read/Delete off DnssecKey.Digest instead, which is stable across both APIs, stops overwriting the write-only signing_attributes block with zero values during Read, and adds a v0->v1 state upgrader so that existing Pulumi stacks with state written by a previous (broken) provider version are migrated automatically instead of losing the resource on their next refresh.
Contributor
Does the PR have any schema changes?Looking good! No breaking changes found. Maintainer note: consult the runbook for dealing with any breaking changes. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6524 +/- ##
=======================================
Coverage 15.91% 15.91%
=======================================
Files 374 374
Lines 91465 91465
=======================================
Hits 14557 14557
Misses 76887 76887
Partials 21 21 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
corymhall
requested changes
Jul 10, 2026
corymhall
left a comment
Member
There was a problem hiding this comment.
Marking as request changes so it doesn't merge. We are discussing internally.
Hi, any progress on this issue? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Customer reported that
aws_route53domains_delegation_signer_recordis affected by an upstream Terraform provider bug: hashicorp/terraform-provider-aws#47928.Symptom: Immediately after a successful
Create, the very nextrefresh/planremoves the resource from state. The followingapplythen fails with:because Terraform/Pulumi tries to re-create a DS record the registry already has.
Root cause:
CreatestoresDnssecKey.Id(formatDS:keytag-algorithm-digesttype-digest) as returned byAssociateDelegationSignerToDomain, butReadlooks the key back up viaGetDomainDetail, which does not reliably echo thatIdback in the same form. The lookup byIdinfindDNSSECKeyByTwoPartKeytherefore never matches, and the resource is treated as gone.Fix
This adds a new upstream patch (
patches/0028-...patch) tointernal/service/route53domains/delegation_signer_record.go, based on the most complete upstream fix candidate (hashicorp/terraform-provider-aws#48165):DnssecKey.Digestinstead ofIdin Create/Read/Delete/findDNSSECKeyByTwoPartKey.Digestis the value that is stable acrossAssociateDelegationSignerToDomainandGetDomainDetail.signing_attributesin Read.GetDomainDetaildoesn't populateAlgorithm/Flags/PublicKeyonDnssecKey, so the previous code was zeroing out the configured values and producing a permanentRequiresReplacediff.DnssecKey.Idfrom the digest before callingDisassociateDelegationSignerFromDomain, since that API still requires the internalId, not the digest.dnssec_key_id/idvalues from the oldDS:keytag-algorithm-digesttype-digestshape down to the bare digest, so existing Pulumi stacks with state from a previously-broken provider aren't dropped on their first refresh after this fix lands. The upgrader is idempotent and leaves malformed values untouched rather than corrupting them.PlanOnlyacceptance test step asserting an empty plan immediately afterCreate— the exact regression this fixes — plus a unit test for the digest-parsing helper used by the state upgrader.Testing
go build ./internal/service/route53domains/...— cleango vet ./internal/service/route53domains/...— cleango build ./...(full upstream module) — cleango test ./internal/service/route53domains/... -v— all unit tests pass (acceptance tests skip withoutTF_ACC/AWS credentials, as expected)./scripts/upstream.sh init -fre-applies all 28 patches (including the new one) cleanly from a clean checkout.No SDK/schema regeneration was needed since the resource's public attribute set (
dnssec_key_id,domain_name,signing_attributes,id) is unchanged — only the internal Create/Read/Delete implementation and schema version changed.Fixes #6526
Created with Eon