carlos / platform Public

Found by Astra reviewing fix/canary-one-label (#207). The gap predates that branch: the instance create door has never checked whether another app in the same account already holds the requested host. #207's canary fix makes it easier to hit, because <canary>-<app> hosts can coincide across apps (canary a of app b-c and canary a-b of app c are both a-b-c).

fix/canary-one-label adds hostHolder, which closes the SEQUENTIAL case. Before writing, the create door refuses with 409 when another app's instance record or a local route holds the host. Two gaps remain:

1. Race. The check runs before the write, and CreateRecord's conditional write only protects the account/app/host key. Two concurrent creates for the same host under different apps can both get 201. Reconcile then skips one, or different placements serve different apps at the same hostname.
2. Aliases and domain claims. hostHolder reads routes and instance records, not global domain claims or route_aliases. On a deployment with platform-domain reservation off, app B can hold x.<acct domain> as an attached alias, and app A can create a real instance on that host. The real route shadows the alias (edge.go route precedence).

The fix needs host-scoped atomic ownership: one object per host, created conditionally, released on delete. The create door, the alias attach and the domains pass should all go through it. Add a concurrent-create test and an alias-vs-instance test.

There are also smaller items from the same review:

• hostHolder costs one sequential GET per other app in the account, inside the handler's 15 s budget;
• it sees only this console box's registry;
• direct-bucket records of apps not listed in SQL are outside the scan.

Review text: /home/paulca/.claude/tmp/canary-review.md (local to DOCS-T1).