[brenzi-agent]

simplex-network/ens-contracts#42 moved reservations out of SimplexController into a new SimplexNamePolicy. Its reservedNames(bytes32) returns the same Reason, and the controller no longer has it. The resolver asks the controller, so on a .simplex deployment of the current simplex contracts that read reverts and every lookup answers 502 upstreamError.

At startup, before its workers start, the resolver now reads each configured controller's namePolicy(), and then reads reservedNames from the policy it names, in the same round as before. .testing's controller is from before name policies: the read reverts, and the controller keeps the reservations. A read that reverts, answers nothing, names no policy or fails with an RPC error is logged as no_name_policy, and reservations are read from the controller, so for a controller that has a name policy every lookup under its TLD answers 502 until a restart (for example, when the node had not yet synced to its setNamePolicy). A node that does not answer stops the resolver (startup_failed), and the container restarts. listening logs each TLD's name policy. After the controller's owner calls setNamePolicy, the resolver must be restarted. No new setting.

Everything else the resolver reads is unchanged: nameExpires, GRACE_PERIOD and labelOf on the registrar, prices and minCharLength on the controller, the oracle's prices, the registry, and the name's resolver.

Tested

• python -m unittest test_snrc_resolve (153 passed) and ruff check. New tests cover the startup read (a policy, an old controller, no policy, no contract, an unconfigured controller, a node that does not answer), the exit at startup, workers that open their own RPC connections after the read, and reservations read from a policy in the same rounds as before.
• A local .simplex deployment on anvil of ens-contracts simplex with SimplexNamePolicy: keep the community terms' text on chain simplex-network/ens-contracts#45, made by webapp: read reservations from the name policy and accept every name's terms on chain simplex.domains#7's dev/deploy.ts. listening names the policy for .simplex. support.simplex answers reserved (internal), and so does its hashed query. bakery.simplex answers registered with its record, and a free name answers available with its price.
• Mainnet .testing through a public RPC: namePolicy() reverts and is logged as no_name_policy. foobar.testing answers registered, and simplex.testing answers reserved (internal).

Not covered: bona fide community names (simplex-network/ens-contracts#40) need the buyer to accept terms before registering. The name response has no field for that, so they answer available as before.

https://claude.ai/code/session_01BxsKd45qytTbangMqJs93F

[brenzi]

test instance results:

The .testing regression test on smp7 passed: the new resolver gives the same answers as before, and they match the chain.

What I checked. I sent name lookups straight to the relays with a small client built from simplexmq’s names branch, at protocol v23 and at v21 (the plain query an older client sends). The names were 830 in all:

all 814 registered .testing names, read from the registrar at block 26290180;
PR 1863’s 14 names;
some extra reserved candidates and subnames.

Compared with the chain, every v23 answer from smp7 is correct:

All 814 registered names answer registered with their own record, and expiry and grace match the registrar to the second.
foobar is registered and also carries its internal reservation.
simplex and simplex-chat answer reserved, internal. So do sub.simplex and sub.foobar, under their reserved parents.
The other 12 answer available and free, with a 6-letter minimum.

The fallback this PR adds. On chain, namePolicy() reverts on the .testing controller. The reservations above prove the resolver falls back to reading them from the controller.

Older clients. At v21, the 814 registered names get their records and the other 16 get NOT_FOUND, as before.

Compared with smp4 and smp8, which I assume still run the previous resolver (I can’t confirm that from outside), all 830 answers are the same at both versions. The one exception is a single smp8 transport failure on linera.testing, which resolved when I retried. All three relays were within a minute of the chain head.

PR 1863’s 14 names answer the same as in that comment, apart from the newer block timestamps.