fix(iot-client): point the UEAZ ATOP fallback at a host that exists - #31
Merged
Conversation
IOT_UEAZ_HOST shipped as a1-ueaz.tuyaeu.com, which is NXDOMAIN — US-East lives under tuyaus.com, not tuyaeu.com. The name has never resolved, so the whole US-East ATOP fallback path was dead: whenever IoT-DNS answered POST /v2/url_config without an httpsUrl, iot_region_to_host(UEAZ, PROD) handed back a name no resolver can answer and the device had nowhere to go. The sibling constants show what the intent was — IOT_AZ_HOST is a1.tuyaus.com and IOT_UEAZ_PRE_HOST is a1-ueaz.wgine.com; only the prod UE entry drifted into the EU domain, and it has been wrong since the initial commit. Probed 2026-08-31: a1-ueaz.tuyaeu.com NXDOMAIN, a1-ueaz.tuyaus.com resolves to 35.212.96.105. a1-ueaz.wgine.com resolves too, but to 100.64.3.152 — RFC 6598 shared address space, reachable only from inside Tuya, which is right for the PRE constant and wrong for PROD. Nothing asserts the constant's value: dns_test.c's PROD mapping test compares iot_region_to_host() against IOT_UEAZ_HOST itself, so it passes either way. That is deliberate — the test guards against a region falling through to the China default, not against a typo in the host — and a test pinning the literal would just restate the header. The failure is only visible against real DNS, which is why AGENTS.md carries the measured facts; its UEAZ note is updated here to say the name was repointed rather than that the path is still dead. Verified: full ctest suite 15/15 on a clean worktree carrying only this commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
heshaoqiong-tuya
force-pushed
the
fix/ueaz-atop-host
branch
from
August 31, 2026 10:01
232ef43 to
4003f5e
Compare
heshaoqiong-tuya
added a commit
that referenced
this pull request
Sep 2, 2026
The Unreleased entry said (#32), the number the fix was expected to get. It merged as #31 (squash commit 3556669) and #32 does not exist yet, so the one link from the one-line entry back to its reasoning pointed at nothing. Also adds the trailing newline AGENTS.md was missing. Whitespace only. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
2 participants
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.
IOT_UEAZ_HOST shipped as a1-ueaz.tuyaeu.com, which is NXDOMAIN — US-East lives under tuyaus.com, not tuyaeu.com. The name has never resolved, so the whole US-East ATOP fallback path was dead: whenever IoT-DNS answered POST /v2/url_config without an httpsUrl, iot_region_to_host(UEAZ, PROD) handed back a name no resolver can answer and the device had nowhere to go. The sibling constants show what the intent was — IOT_AZ_HOST is a1.tuyaus.com and IOT_UEAZ_PRE_HOST is a1-ueaz.wgine.com; only the prod UE entry drifted into the EU domain, and it has been wrong since the initial commit.
Probed 2026-08-31: a1-ueaz.tuyaeu.com NXDOMAIN, a1-ueaz.tuyaus.com resolves to 35.212.96.105. a1-ueaz.wgine.com resolves too, but to 100.64.3.152 — RFC 6598 shared address space, reachable only from inside Tuya, which is right for the PRE constant and wrong for PROD.
Nothing asserts the constant's value: dns_test.c's PROD mapping test compares iot_region_to_host() against IOT_UEAZ_HOST itself, so it passes either way. That is deliberate — the test guards against a region falling through to the China default, not against a typo in the host — and a test pinning the literal would just restate the header. The failure is only visible against real DNS, which is why AGENTS.md carries the measured facts; its UEAZ note is updated here to say the name was repointed rather than that the path is still dead.
Verified: full ctest suite 15/15 on a clean worktree carrying only this commit.