fix(txt-registry): skip creation of already-existing TXT records (#4914) #5459

u-kai · 2025-05-24T09:43:14Z

What does it do ?

Adds a cache-based filter to TXTRegistry so that External-DNS no longer
tries to recreate TXT records that already exist in the provider.
Fixes #4914

Motivation

When only the data record (A/CNAME) is removed, External-DNS next sync loop
recreates that record and also tries to create the unchanged TXT record,
which providers like Route53 reject with “record already exists”.
Caching existing TXT entries and skipping them in ApplyChanges() prevents
this failure.

More

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

k8s-ci-robot · 2025-05-24T09:43:23Z

Welcome @u-kai!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

k8s-ci-robot · 2025-05-24T09:43:24Z

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.

mloiseleur · 2025-05-24T16:59:49Z

Thanks.
I'm not sure of this approach 🤔 It may increase memory usage on big users.
/ok-to-test
cc @szuecs

mloiseleur · 2025-05-24T17:17:20Z

What happens the txt record has also been deleted ?
It will still be in this cache, so not re-created ?

u-kai · 2025-05-24T23:28:42Z

@mloiseleur
Thanks for pointing that out — you’re right, the current patch keeps the TXT snapshot alive across the entire reconcile loop.
Apologies — I overlooked this in the first draft.

Proposed update

func (r *TXTRegistry) ApplyChanges(ctx context.Context, c *plan.Changes) error {
    ...

    if err := r.provider.ApplyChanges(ctx, c); err != nil {
        return err
    }

    // ✨ NEW: drop the snapshot so the next Records() call rebuilds it
    r.existingTXT = txtSnapshot{}  // formerly existingTXT

    return nil
}

Memory – The snapshot now lives for just one reconciliation pass.
In my understanding, GC might run a little later than before, but the peak heap usage right after r.provider.Records() when the full slice of endpoints is allocated — remains exactly the same.
If I’m mistaken, please let me know. 🙇
Correctness – If a TXT record is deleted between loops, the next Records() call rebuilds the snapshot without it, so the data record will be recreated.

Let me know if this per-loop cleanup addresses your concerns; I can push the change right away. 🙇‍♂️

ivankatliarchuk · 2025-05-25T09:10:20Z

There are concerns Regarding TXT Caching as a Solution

I'm unclear how caching will resolve the underlying issue. From my perspective, this looks like a bug in either the CRD source, the TXT registry, or how records and plans are being handled. Instead of identifying and fixing that root cause, the current proposal is to introduce a new feature – TXT caching. The issue missing how-to reproduce, what the arguments are and version for reported bug is ~0.13, when latest version is 0.17, which means, the issue may no longer even exist.

The approach could actually worsen the situation for TXT records. Implementing a cache on a stateless service means the problem is likely to reappear during restarts or new service startups.

This proposed caching mechanism isn't a fix. We need to find the root cause of the problem. The expectation should be to reproduce the issue in a controlled environment and then try to pinpoint where the bug lies.

Relevant issue #4998

It appears there's a bug within either the CRD source, the TXT registry, or the mechanism for pulling records for a specific provider and handling the plan. Instead of addressing this underlying bug, the decision has been made to introduce a new feature: TXT caching.

ivankatliarchuk · 2025-05-25T10:32:50Z

TXT registry already have a cache

external-dns/registry/txt.go

Line 46 in 36bc7d6

recordsCache []*endpoint.Endpoint

and local endpoints and TXT records cache https://github.com/kubernetes-sigs/external-dns/blob/master/registry/txt.go#L138-L141

This is a high-impact issue, and without being able to reproduce it, it's tough to pinpoint the exact cause. It's even possible that upsert-only failed, but everything works fine when the sync flag is set.

I propose to start with:

Adding a unit test that specifically shows the issue where the record is deleted but the registry record persists.
Reproducing the actual bug on a local cluster using the Route53 provider and the latest external-dns.
Implementing the fix once the root cause is identified.

First two could be done in any order, but with focus on reproducing the problem and providing a unit test, that reveals the bug.

This is currently just an assumption, and without reproducing it, it's hard to be certain. We need to confirm that if a TXT registry record exists without a corresponding managed record (like A, AAAA, or CNAME), we either:

Mark the TXT registry record for deletion (though this won't work with upsert-only) and then apply the new changes, OR
Leave the TXT registry record untouched and only update the actual record.

ivankatliarchuk · 2025-05-25T10:35:20Z

Fixes #5340

ivankatliarchuk · 2025-05-25T10:41:58Z

Fixes #5003

^ this issue is related, but not sure where scope of the fix will cover it

u-kai · 2025-05-25T10:48:26Z

@ivankatliarchuk

Thank you for your feedback.

Initially, I approached this by introducing a caching mechanism.
However, based on mloiseleur suggestion, I revised the implementation to create a temporary data structure that exists only between the Records and ApplyChanges phases.
This structure functions similarly to a filter: it identifies and excludes any TXT records that already exist, preventing their re-creation. Once ApplyChanges is executed, this temporary structure is cleaned up.

The primary issue I'm addressing is ensuring that ExternalDNS can recreate an A record if it was accidentally deleted. Currently, when attempting to create an A record, ExternalDNS also tries to create a corresponding TXT record via the TXTRegistry.
If the TXT record already exists, providers like Route53 return an error, causing the entire operation to fail.

To resolve this, I implemented a mechanism to store existing TXT records during the Records phase. Before ApplyChanges attempts to create new records, it checks against this stored data to ensure it doesn't attempt to recreate existing TXT records, thereby avoiding errors.

Regarding recordsCache, I understand now that it's intended for non-TXT records and is scoped differently than my current change.
In contrast, my approach is limited to TXT records only, and the snapshot is used strictly within a single reconciliation loop to avoid stale state.
So while the naming may appear similar, the intention and scope are different.

I’ve pushed the updated implementation based on this approach.

Please let me know if I misunderstood any part of your suggestion — happy to revise if needed!

u-kai · 2025-05-25T10:49:15Z

Hi @mloiseleur, I mentioned earlier that I would wait for your confirmation before pushing the changes, but I received a detailed comment from @ivankatliarchuk and pushed the revised implementation to help clarify the current behavior.

The latest code uses a temporary structure between Records and ApplyChanges instead of caching across reconciliation loops, as previously discussed.

Let me know if this direction still looks good to you — I’m happy to adjust if needed!

ivankatliarchuk · 2025-05-25T10:51:52Z

Have you managed to validate that issue is still present or it's related to specific flags

upsert-only
sync
?

ivankatliarchuk · 2025-05-25T11:11:56Z

relates: #3977

u-kai · 2025-05-25T11:12:42Z

@ivankatliarchuk

Yes, I was able to reproduce the issue with both --policy=sync and --policy=upsert-only.
For clarity, I'm using hoge.com here as a placeholder — the actual domain has been replaced.

Environment

branch: master

command:

 external-dns \
--provider aws \
--registry txt \
--txt-owner-id demo \
--policy sync \ # and upsert-only
--log-level debug \
--source ingress

ingress resource

apiVersion: networking.k8s.io/v1
 kind: Ingress
metadata:
  name: demo-wild
  annotations:
    external-dns.alpha.kubernetes.io/aws-weight: "100"
    external-dns.alpha.kubernetes.io/hostname: api.hoge.com
    external-dns.alpha.kubernetes.io/set-identifier: demo
spec:
  rules:
    - host: "api.hoge.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: demo-service
                port:
                  number: 80

Steps to Reproduce

Deploy ExternalDNS.
Deploy the above Ingress and let ExternalDNS create the records.
Manually delete the A record for api.hoge.com from Route53.

Wait for the next reconciliation loop.

Result

On the next loop, ExternalDNS tries to recreate the A record and the associated TXT record.
However, since the TXT record still exists, Route 53 throws an error due to the attempted re-creation of an already-existing record.

DEBU[0001] Adding api.hoge.com. to zone hoge.com. [Id: /hostedzone/ZONEIDXXXXXXXXX]
DEBU[0001] Adding api.hoge.com. to zone hoge.com. [Id: /hostedzone/ZONEIDXXXXXXXXX]
DEBU[0001] Adding a-api.hoge.com. to zone hoge.com. [Id: /hostedzone/ZONEIDXXXXXXXXX]
INFO[0001] Desired change: CREATE a-api.hoge.com TXT  profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
INFO[0001] Desired change: CREATE api.hoge.com A   profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
INFO[0001] Desired change: CREATE api.hoge.com TXT  profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
...
DEBU[0061] Adding api.hoge.com. to zone hoge.com. [Id: /hostedzone/ZONEIDXXXXXXXXX]
DEBU[0061] Adding api.hoge.com. to zone hoge.com. [Id: /hostedzone/ZONEIDXXXXXXXXX]
DEBU[0061] Adding a-api.hoge.com. to zone hoge.com. [Id: /hostedzone/ZONEIDXXXXXXXXX]
INFO[0061] Desired change: CREATE a-api.hoge.com TXT  profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
INFO[0061] Desired change: CREATE api.hoge.com A   profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
INFO[0061] Desired change: CREATE api.hoge.com TXT  profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
ERRO[0061] Failure in zone hoge.com. when submitting change batch: operation error Route 53: ChangeResourceRecordSets, https response error StatusCode: 400, RequestID: 08d2eafe-c886-46d3-bd49-c5f905a7d3ee, InvalidChangeBatch: [Tried to create resource record set [name='a-api.hoge.com.', type='TXT', set-identifier='demo'] but it already exists, Tried to create resource record set [name='api.hoge.com.', type='TXT', set-identifier='demo'] but it already exists]  profile=default zoneID=/hostedzone/ZONEIDXXXXXXXXX zoneName=hoge.com.
ERRO[0062] Failed to do run once: soft error
failed to submit all changes for the following zones: [/hostedzone/ZONEIDXXXXXXXXX]

registry/txt.go

u-kai · 2025-05-25T22:40:43Z

@ivankatliarchuk
Thanks a lot for the review and helpful suggestion!
I've reflected the changes accordingly.

I'm currently reviewing the test cases and will follow up once everything is ready.

ivankatliarchuk · 2025-05-26T08:57:20Z

registry/txt.go

+		generatedTXTs := im.generateTXTRecord(r)
+		for _, txt := range generatedTXTs {
+			// If the TXT record is already managed by this instance, skip it
+			if im.existingTXTs.isManaged(txt) {
+				continue
+			}
+			filteredChanges.Create = append(filteredChanges.Create, txt)
+		}


I do not understand this logic behind the solution.
Why we could not have something simple like?

for _, r := range filteredChanges.Create { if im.existingTXTs.is(not)Managed(r) { continue } if r.Labels == nil { r.Labels = make(map[string]string) } r.Labels[endpoint.OwnerLabelKey] = im.ownerID if im.cacheInterval > 0 { im.addToCache(r) } }

Thanks for the suggestion!

The reason the logic is structured this way is because filteredChanges.Create does not initially contain TXT records.
The TXT records are generated on the fly using im.generateTXTRecord(r), and those are what I intend to filter using existingTXTs.

Checking r directly (as in your example) wouldn’t work in this case, since it’s typically an A or CNAME record, not the TXT itself.
Let me know if I misunderstood your suggestion!

Current implementation seems quite expensive in terms for computation.

It should be possible to pass any record to im.existingTXTs.is(not)Managed and validate it somehow.

Just pushed a refactor — the generateTXTRecordWithFilter part is a bit more involved, but the main loop is now cleaner and should be more efficient overall.
Open to feedback, let me know what you think!

mloiseleur · 2025-06-13T06:50:24Z

@u-kai Would you please rebase this PR on top of master, where the flaky test has been fixed ?

szuecs · 2025-06-13T10:43:58Z

Also, when only the TXT record is deleted, it currently won’t be recreated — this is a separate issue that I plan to address in a future PR, also using existingTXTs.

We don't want to recreate TXT records in this case!
It's the mechanism that identifies the ownership and if you mix a zone with multiple external-dns or external-dns and manual records you would create a mess if you would recreate the deleted txt record. A txt record deletion means, that you don't want to let this record being owned by the external-dns instance.

szuecs · 2025-06-13T10:48:10Z

registry/txt.go

+}
+
+// isNotManaged reports whether the given endpoint's TXT record is absent from the existing set.
+// Used to determine whether a new TXT record needs to be created.


Maybe the doc string is wrong, but we do not want to recreate the TXT record!

What I meant here was that this is used to determine whether a TXT record should be created — I didn’t intend to say that it is about recreating the record.
But if this is confusing, I’m happy to remove it.

szuecs · 2025-06-13T10:51:00Z

registry/txt.go

+func (im *existingTXTs) reset() {
+	// Reset the existing TXT records for the next reconciliation loop.
+	// This is necessary because the existing TXT records are only relevant for the current reconciliation cycle.
+	im.entries = make(map[recordKey]struct{})


This is a possible data race, I think we should guard all access to im.entries by a Mutex

I don't think we need a Mutex here. From what I can see, TXTRegister is only used inside Controller.RunOnce, which doesn't seem to use any goroutines.
Also, other cache fields in TXTRegister are being updated without a Mutex as well, so it seems consistent not to add one here.

szuecs · 2025-06-13T10:53:35Z

registry/txt.go

@@ -244,7 +301,9 @@ func (im *TXTRegistry) generateTXTRecord(r *endpoint.Endpoint) []*endpoint.Endpo
 			txt.WithSetIdentifier(r.SetIdentifier)
 			txt.Labels[endpoint.OwnedRecordLabelKey] = r.DNSName
 			txt.ProviderSpecific = r.ProviderSpecific
-			endpoints = append(endpoints, txt)
+			if filter(txt) {


That's basically if true as far as I understand https://github.com/kubernetes-sigs/external-dns/pull/5459/files#r2107584832 , right?
If so please drop the added complexity. If we need filtering than have it but other than that I don't think we should have an if branch here.

I think we still need the if here because we use isNotManaged for filtering.
The purpose of this change is to filter out existing TXT records when an A record was mistakenly deleted and later recreated by External-DNS.
This filtering is necessary because trying to create a TXT record that already exists would result in an error. So if a TXT record already exists, we avoid creating it again.

This also addresses the comment raised here: #5459 (comment).

szuecs · 2025-06-13T10:53:46Z

registry/txt.go

@@ -259,14 +318,18 @@ func (im *TXTRegistry) generateTXTRecord(r *endpoint.Endpoint) []*endpoint.Endpo
 		txtNew.WithSetIdentifier(r.SetIdentifier)
 		txtNew.Labels[endpoint.OwnedRecordLabelKey] = r.DNSName
 		txtNew.ProviderSpecific = r.ProviderSpecific
-		endpoints = append(endpoints, txtNew)
+		if filter(txtNew) {


same https://github.com/kubernetes-sigs/external-dns/pull/5459/files#r2144764548

see hear 🙇 #5459 (comment)

…ernetes-sigs#4914)

…cords and ApplyChanges

…ering

… test

…to reduce memory usage

szuecs · 2025-06-13T10:56:09Z

registry/txt.go

@@ -279,7 +342,7 @@ func (im *TXTRegistry) ApplyChanges(ctx context.Context, changes *plan.Changes)
 		}
 		r.Labels[endpoint.OwnerLabelKey] = im.ownerID

-		filteredChanges.Create = append(filteredChanges.Create, im.generateTXTRecord(r)...)
+		filteredChanges.Create = append(filteredChanges.Create, im.generateTXTRecordWithFilter(r, im.existingTXTs.isNotManaged)...)


I am not sure if this is correct

see hear 🙇 #5459 (comment)

szuecs

A bit of cleanup and missing negative tests

For sure we do not want to recreate ownership records.

szuecs · 2025-06-13T10:57:45Z

registry/txt_test.go

+				newEndpointWithOwner("record-1.test-zone.example.org", "1.1.1.1", endpoint.RecordTypeA, ownerId),
+			},
+		},
+		// TODO: Test TXT record regeneration when only A/CNAME records exist.


szuecs · 2025-06-13T10:59:56Z

registry/txt_test.go

+			expectedCreate: []*endpoint.Endpoint{
+				newEndpointWithOwner("record-1.test-zone.example.org", "1.1.1.1", endpoint.RecordTypeA, ownerId),
+			},
+		},


There are tests missing for:

do not recreate $RR, if another external-dns instance owns the record

do not recreate $RR, if there is no owner

Could you clarify in what situation you think this case would occur? 🙇
In this PR, the tests are intended to verify that records (such as A or CNAME) are properly created when they are desired (e.g. via Ingress host settings).
At this point, the records do not yet exist, so naturally they will have no owner at that stage.
In that sense, the "no owner" case is simply the expected initial state, not an exceptional condition we should test for.

Regarding ownership conflicts: I believe this would happen if multiple external-dns instances were deployed in the same cluster and watching the same resources (e.g. the same Ingress), without proper isolation (such as domainFilter).
However, in my view, this is a misconfiguration, and not something we should test for here.

u-kai · 2025-06-13T11:05:31Z

@szuecs
Thank you for review!

We don't want to recreate TXT records in this case!
It's the mechanism that identifies the ownership and if you mix a zone with multiple external-dns or external-dns and manual records you would create a mess if you would recreate the deleted txt record. A txt record deletion means, that you don't want to let this record being owned by the external-dns instance.

You're right — there are cases where deleting the TXT record is intentional to relinquish ownership.
In that case, recreating it would indeed be incorrect.
However, if the goal is to stop managing certain records, wouldn't it be more appropriate to configure domainFilter or similar mechanisms? What do you think about that approach?

into fix/issue-4914

ivankatliarchuk

rest seems legit to me

We just w8 for @szuecs view

ivankatliarchuk · 2025-07-03T07:01:38Z

registry/txt.go

+	}
+}
+
+func (im *existingTXTs) add(r *endpoint.Endpoint) {


function not fully covered

But agree, we need to be super careful, as pretty much every deployment rely on txt registry

k8s-ci-robot · 2025-07-03T07:03:36Z

[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 ivankatliarchuk. 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

k8s-ci-robot requested a review from mloiseleur May 24, 2025 09:43

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label May 24, 2025

k8s-ci-robot requested a review from szuecs May 24, 2025 09:43

k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label May 24, 2025

k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label May 24, 2025

k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 24, 2025

This comment was marked as off-topic.

Sign in to view

u-kai mentioned this pull request May 25, 2025

test(metrics): replace random value with a static value #5462

Merged

3 tasks

This comment was marked as off-topic.

Sign in to view

ivankatliarchuk mentioned this pull request May 25, 2025

Capture TXT registry and format related issues #5465

Open

ivankatliarchuk suggested changes May 25, 2025

View reviewed changes

registry/txt.go Outdated Show resolved Hide resolved

registry/txt.go Outdated Show resolved Hide resolved

registry/txt.go Outdated Show resolved Hide resolved

registry/txt.go Outdated Show resolved Hide resolved

k8s-ci-robot assigned ivankatliarchuk May 25, 2025

ivankatliarchuk suggested changes May 26, 2025

View reviewed changes

szuecs reviewed Jun 13, 2025

View reviewed changes

u-kai added 10 commits June 13, 2025 19:55

fix(txt-registry): skip creation of already-existing TXT records (kub…

e9a022b

…ernetes-sigs#4914)

refactor(registry): store existing TXT records temporarily between Re…

61e4d49

…cords and ApplyChanges

refactor: apply review suggestion for code cleanup

b660bc6

test: add coverage for recreating A/CNAME records when TXT exists

596bb2d

refactor: extract generateTXTRecordWithFilter to avoid redundant filt…

4444a1d

…ering

test: add comprehensive test cases and isolate test data for t.Parallel

05e4d4e

docs: clarify comment for isNotManaged to reflect actual behavior

6b8fe6a

fix: apply SetIdentifier before filtering TXT records, add regression…

d347e29

… test

chore: fix lint warnings

cc6d91e

refactor: use key struct instead of concatenated string for map keys …

b100166

…to reduce memory usage

szuecs reviewed Jun 13, 2025

View reviewed changes

u-kai force-pushed the fix/issue-4914 branch from 2af1c70 to b100166 Compare June 13, 2025 10:56

szuecs requested changes Jun 13, 2025

View reviewed changes

k8s-ci-robot assigned szuecs Jun 13, 2025

ivankatliarchuk mentioned this pull request Jun 18, 2025

fix: TXT record when killed at the wrong time #4117

Open

2 tasks

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 25, 2025

Merge branch 'master' of https://github.com/kubernetes-sigs/external-dns

2601def

into fix/issue-4914

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 27, 2025

ivankatliarchuk suggested changes Jul 3, 2025

View reviewed changes

k8s-ci-robot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 3, 2025

ivankatliarchuk mentioned this pull request Jul 11, 2025

fix(provider/aws): null pointer when records mailformed #5639

Merged

3 tasks

ivankatliarchuk mentioned this pull request Jul 24, 2025

refactor: Pair of lists to list of pairs in update changes #5681

Open

3 tasks

fix(txt-registry): skip creation of already-existing TXT records (#4914) #5459

Are you sure you want to change the base?

fix(txt-registry): skip creation of already-existing TXT records (#4914) #5459

Conversation

u-kai commented May 24, 2025

What does it do ?

Motivation

More

Uh oh!

k8s-ci-robot commented May 24, 2025

Uh oh!

k8s-ci-robot commented May 24, 2025

Uh oh!

mloiseleur commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mloiseleur commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

u-kai commented May 24, 2025

Proposed update

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

ivankatliarchuk commented May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ivankatliarchuk commented May 25, 2025

Uh oh!

ivankatliarchuk commented May 25, 2025

Uh oh!

ivankatliarchuk commented May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

u-kai commented May 25, 2025

Uh oh!

u-kai commented May 25, 2025

Uh oh!

ivankatliarchuk commented May 25, 2025

Uh oh!

ivankatliarchuk commented May 25, 2025

Uh oh!

u-kai commented May 25, 2025

Environment

Steps to Reproduce

Result

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

u-kai commented May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mloiseleur commented Jun 13, 2025

Uh oh!

szuecs commented Jun 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mloiseleur commented May 24, 2025 •

edited

Loading

mloiseleur commented May 24, 2025 •

edited

Loading

ivankatliarchuk commented May 25, 2025 •

edited

Loading

ivankatliarchuk commented May 25, 2025 •

edited

Loading

u-kai commented May 25, 2025 •

edited

Loading