Found while fixing the Studio top bar's package name (objectui#7254, PR #7366). Not fixed there — that card is about what the switcher NAMES, this is about its fetch's error posture.
PackageSwitcher in packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx:
fetchPackages()
.then((parsed) => { if (!cancelled) setPkgs(parsed); })
.catch(() => {
/* leave null — switcher still works for navigation-free display */
});
pkgs stays null, and the trigger renders current?.name ?? packageId. So any failure of GET /api/v1/packages — a 503 from the durable half, a network drop, an auth expiry — leaves the Studio top bar showing the raw reverse-domain package id (app.b2r4) forever, with no toast, no retry and no console line. The author sees something that looks like a name, and it is an id.
The comment's justification is real (navigation still works), but it argues for degrading, not for degrading silently: the same code path is what makes a genuine "this package has no declared name" indistinguishable from "the list never loaded".
Worth deciding between: surface the failure (the sibling openManage path already does toast.error(formatMetadataError(e))), retry once, or at minimum distinguish the loading/failed state from the loaded one so the trigger can say which it is. The same .catch shape appears in the other two fetchPackages() call sites in that file.
Found while fixing the Studio top bar's package name (objectui#7254, PR #7366). Not fixed there — that card is about what the switcher NAMES, this is about its fetch's error posture.
PackageSwitcherinpackages/app-shell/src/views/studio-design/StudioDesignSurface.tsx:pkgsstaysnull, and the trigger renderscurrent?.name ?? packageId. So any failure ofGET /api/v1/packages— a 503 from the durable half, a network drop, an auth expiry — leaves the Studio top bar showing the raw reverse-domain package id (app.b2r4) forever, with no toast, no retry and no console line. The author sees something that looks like a name, and it is an id.The comment's justification is real (navigation still works), but it argues for degrading, not for degrading silently: the same code path is what makes a genuine "this package has no declared name" indistinguishable from "the list never loaded".
Worth deciding between: surface the failure (the sibling
openManagepath already doestoast.error(formatMetadataError(e))), retry once, or at minimum distinguish the loading/failed state from the loaded one so the trigger can say which it is. The same.catchshape appears in the other twofetchPackages()call sites in that file.