carlos canary: canaryHost builds a two-label host the create door refuses Issueclosed
claude agent, operated by paul@keymail.devdriven by paul@keymail.devsession 57e315fe · claude-code/2.1.284 · DOCS-T1
Found while building nearest-region Task 22 (branch design-nearest-region).
canaryHost (canary.go:210) builds <canary>.<app>.<domain>, where domain is the instance manifest's Domain (<sqid>.<apps-domain>). The instance create door checks provision.ValidHost(host, m.Domain) (apiinstances.go:~698). That requires exactly ONE label before the domain: controlname.ValidLabel on "<canary>.<app>" fails because of the dot.
So on main, carlos canary appears to be refused at create with "invalid host". The Task 22 implementer could not run a canary-create end-to-end test for this reason, and says the problem predates the region work.
Next steps:
Confirm against a real console. Was this ever working? Did the manifest Domain or ValidHost change?
Decide on a fix: either flatten the canary host to one label (e.g. <canary>-<app>.<domain>), or accept a two-label prefix for canary records. The first changes the documented README scheme.
Out of scope for the nearest-region build. Filed so it isn't lost.
claude agent, operated by paul@keymail.devdriven by paul@keymail.devsession 57e315fe · claude-code/2.1.284 · DOCS-T1
Confirmed by review.
canaryHost (name + "." + app + "." + domain) landed in 537c4a1e on 2026-09-04, as part of #384.
ValidHost has required exactly one label since d40839f8 (2026-08-04). internal/provision/provision_test.go:131 pins a.b.go.tito.io under go.tito.io as invalid.
So carlos canary's create has been refused with "invalid host" since #384 landed.
Rechannel and set-environment use ValidHostShape, so reusing an existing canary works. Only creating one fails.
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 57e315fe · claude-code/2.1.284 · DOCS-T1
Fixed on main as 04cd2d78 (fix/canary-one-label), which ships in v0.23.0.
Canary hosts are now one label, <name>-<app>.<domain>. ValidHost is unchanged.
A name plus app longer than 63 characters is refused. An app whose name ends in a dash can't have canaries.
A non-canary record already sitting on the computed host is refused instead of being rechannelled.
The instance create door now refuses (409) a hostname that another app in the same account already holds, whether by instance record, local route or global hostname claim. The remaining concurrent-create race is #232. The copy was approved by Paul on 2026-10-05.