fix(txt-register): reset existingTXTs even when ApplyChanges is skipped to avoid stale TXT records

[u-kai]

What does it do ?

This PR fixes an issue where stale TXT record information could remain when ApplyChanges was not called.
Previously, existingTXTs were only reset via a defer inside ApplyChanges, but when plan.Changes.HasChanges() was false (i.e., no DNS changes to apply), that method was skipped, and the cached TXT records were not cleared.

This change ensures that existingTXTs are always reset, so the latest TXT record state is correctly reflected in subsequent reconciliation loops.

Motivation

When ExternalDNS detected no DNS changes (plan.Changes.HasChanges() == false), ApplyChanges was skipped and the existingTXTs reset logic inside it was not executed.
As a result, outdated TXT record information could persist and cause ExternalDNS to skip creating new TXT records for newly created A/AAAA records.

By resetting existingTXTs every time (even when there are no changes), we ensure that TXT ownership information always stays in sync with the current state in Route53.

Fixes: #5894

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[k8s-ci-robot]

Hi @u-kai. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[u-kai]

I confirmed that this test failed on previous versions with the following output:

kai@kainoMacBook-Pro external-dns % go test ./registry/...
--- FAIL: TestRecreateRecordAfterDeletion (0.00s)
    txt_test.go:2190:
                Error Trace:    /Users/kai/external-dns/registry/txt_test.go:2190
                Error:          Should be true
                Test:           TestRecreateRecordAfterDeletion
                Messages:       Expected records after reconciliation: [bar.test-zone.example.org 0 IN A  1.2.3.4 [] a-bar.test-zone.example.org 0 IN TXT  "heritage=external-dns,external-dns/owner=foo" []], but got: [bar.test-zone.example.org 0 IN A  1.2.3.4 []]
FAIL
FAIL    sigs.k8s.io/external-dns/registry       0.345s
FAIL

[mloiseleur]

/ok-to-test

[szuecs]

/lgtm

[u-kai]

@szuecs @mloiseleur
Thank you for the approval.
I believe the failing test in CI has already been fixed and merged into the main branch.
Since the PR has been approved, would you recommend that I pull the latest changes from main, or would it be better to have the CI job restarted?

[mloiseleur]

@u-kai You need to rebase on master branch, then the CI will pass green.

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from szuecs. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[u-kai]

@mloiseleur @szuecs

I’ve merged the latest changes from the master branch.
Please take another look.