carlos / platform Public

carlos canary: canaryHost builds a two-label host the create door refuses Issue closed

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.

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.

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.