Seed the base realm in canonical form - #5925
Conversation
The realm list seeded the base realm with its alias URL while an instance's id is a registered prefix, so the base realm was the one entry whose form disagreed with the ids it gets compared against. User and catalog entries arrive from `_realm-auth` and `_catalog-realms` as real URLs with no prefix to fold to, and were already canonical. Recent-cards paid for the disagreement directly: it unresolved both an index card id and a card's own id through the VirtualNetwork before comparing them. With both sides canonical the comparison is a plain set lookup. Two consumers derived segments by parsing, which only a URL admits: `routes/index.gts` matched a card path against a realm path via `new URL(realm).pathname`. That throws for a prefix. The realm picker took its label from the last path segment inside a `try`, so a prefix answered "Unknown Workspace" instead of the realm's name — a wrong label rather than an error. Both now take the segments of whichever form they are handed, through one helper that documents why parsing loses the prefix case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Preview deploymentsHost Test Results 1 files ± 0 1 suites ±0 1h 48m 24s ⏱️ + 9m 31s Results for commit 1cc4c33. ± Comparison against earlier commit 3533be8. For more details on these errors, see this check. Realm Server Test Results 1 files ±0 1 suites ±0 18m 59s ⏱️ + 3m 39s Results for commit 1cc4c33. ± Comparison against earlier commit 3533be8. |
Two paths took a realm identifier straight to `new URL` and so broke once the base realm entered the list in prefix form. Both had the value arrive through a `string` parameter, which erases the brand, so neither the typechecker nor the lint rule could see them — the host suite found them. `getOrCreateRealmResource` keys a realm resource by URL and logs in with one, so it now resolves a registered prefix first. `info()` two methods away already did exactly that; this is the same normalization at the sibling entry point. `getRealmServersForRealms` skipped realms served by the test realm's origin. A prefix has no origin, so the identifier resolves before the comparison rather than being parsed as if it were already a URL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
[Claude Code 🤖] Parking this as a draft — the estimate behind it turned out to be wrong by an order of magnitude, and the groundwork has moved. What the measurement says. Run against a local environment-mode stack, one module (
The three-line seed change fails 57 of 81 tests in a single module. The dominant errors are two Why that changes the shape. This is not a seed fix with a handful of consumers. It needs a systematic pass over everything treating a realm identifier as a URL, including two categories the original scoping missed: wire boundaries (a prefix realm reaching a search request produces Where the good parts went. The four consumer fixes are split out as CS-12692, branch If you pick this up, don't resume from this branch's state — CS-12686 has been rewritten with the numbers above and a suggested approach. The short version: work behind the local host-test loop rather than CI (about six minutes per answer versus a CI round), and baseline every module against main in the same environment first, because these failures look environmental and are not. Recipe and scripts are in Left open as a draft rather than closed so the partial fixes and this history stay findable; the branch survives either way. |
1 participant
Claude: The realm list seeded the base realm with its alias URL while an instance's id is a registered prefix, so the base realm was the one entry whose form disagreed with the ids it gets compared against. User and catalog entries arrive from
_realm-authand_catalog-realmsas real URLs with no prefix to fold to, and were already canonical.Recent-cards paid for the disagreement directly: it unresolved both an index card id and a card's own id through the VirtualNetwork before comparing them. With both sides canonical the comparison is a plain set lookup.
Two consumers derived segments by parsing, which only a URL admits:
routes/index.gtsmatched a card path against a realm path vianew URL(realm).pathname. That throws for a prefix.The realm picker took its label from the last path segment inside a
try,so a prefix answered "Unknown Workspace" instead of the realm's name — a
wrong label rather than an error.
Both now take the segments of whichever form they are handed, through one helper that documents why parsing loses the prefix case.