ports/zephyr-cp/common-hal/socketpool/SocketPool.c:105-108:
int err = socketpool_getaddrinfo_common(host, port, &hints, &res);
if (err != 0 || res == NULL) {
common_hal_socketpool_socketpool_raise_gaierror_noname();
}Every nonzero return becomes the same exception, built with a literal SOCKETPOOL_EAI_NONAME.
DNS_EAI_NONAME appears nowhere in Zephyr's resolve.c, so the code Python sees is one the
resolver cannot even produce.
The practical cost is that this port cannot distinguish "no such name" from "resolver is dead"
from "network is down". A dead socket-service thread and a genuine NXDOMAIN are the same
exception with the same errno. That is a large part of why the ZVFS_POLL_MAX bug read as a
name-resolution problem for as long as it did.
Suggested fix is to map the Zephyr return through to a meaningful errno rather than collapsing
everything to NONAME.
ports/zephyr-cp/common-hal/socketpool/SocketPool.c:105-108:Every nonzero return becomes the same exception, built with a literal
SOCKETPOOL_EAI_NONAME.DNS_EAI_NONAMEappears nowhere in Zephyr'sresolve.c, so the code Python sees is one theresolver cannot even produce.
The practical cost is that this port cannot distinguish "no such name" from "resolver is dead"
from "network is down". A dead socket-service thread and a genuine NXDOMAIN are the same
exception with the same errno. That is a large part of why the ZVFS_POLL_MAX bug read as a
name-resolution problem for as long as it did.
Suggested fix is to map the Zephyr return through to a meaningful errno rather than collapsing
everything to NONAME.