finding(app-shell): onManageChanged reads a failed package-list refresh as "the package was deleted" and evicts the author to /home

[claude]

Observation

Found while fixing objectui#7368 (the PackageSwitcher fetch error posture). Deliberately
not fixed there: that card is about the switcher's silence, this one is about a wrong
decision the same silence hides, and the correct behaviour needs a ruling rather than a
one-line toast.

onManageChanged in packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx
(:340-354 on origin/main 900f8d995) — the callback the PackageDetailSheet fires after any
package lifecycle action (disable / duplicate / delete / publish / manifest edit):

const onManageChanged = React.useCallback(async () => {
  let list: PkgEntry[] = [];
  try {
    list = await fetchPackages();
    setPkgs(list);
  } catch {
    /* keep the stale list */
  }
  const managedId = manage?.manifest.id;
  if (!managedId) return;
  if (!list.some((p) => p.id === managedId)) {
    // Deleted — only navigate away if it was the package we're editing.
    if (managedId === packageId) {
      const next = list[0];
      navigate(next ? `/studio/${encodeURIComponent(next.id)}/${tab}` : '/home');
    }
    return;
  }
  ...

The catch comment says "keep the stale list". That is true of the pkgs state — which is
simply not written — but not of the local list, which was initialised to [] and stays
[]. Three lines later !list.some(...) is therefore always true, so a failed refresh takes
the branch labelled // Deleted. If the managed package is the one under the editor, the surface
navigates away: list[0] is undefined, so the destination is /home.

Net effect: a transient failure of GET /api/v1/packages — a 503 from the durable half, a
network blip, an auth expiry — immediately after any package lifecycle action reads as "your
package was deleted" and silently evicts the author from the Studio editor to the home page.
No toast, no confirmation, and the package is still there.

The .catch is the same shape objectui#7368 is about, and this is the fourth call site named in
that card's triage. The other three are handled in the PR for #7368; this one is held back
because a toast alone would leave the eviction firing.

Worth deciding

1. Skip the eviction check when the refresh failed — treat "I could not find out" as "no
   information", not as "gone". Cheapest, and matches the sibling catch two blocks down
   (/* keep the current snapshot */), which already declines to act on a failure.
2. Re-derive from the state list rather than the local [], so a failed refresh falls back
   to what the switcher last knew.
3. Report the refresh failure as well (app-shell(studio): PackageSwitcher swallows the package-list fetch failure, leaving the raw package id in the top bar #7368's posture), independently of 1/2.

Re-check

grep -n "onManageChanged" -A 20 packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx

Related, not a duplicate: objectui#7373 is about the destination of recovery redirects
(hard-coded /home vs the declared landing page). This card is about the redirect firing at all,
on a false premise.

---

Generated by Claude Code

[claude]

Claim: PM 席（domain:ui lane）认领本卡并派发给 os-dev 执行席。

• Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
• Branch: claude/issue-7821-onmanagechanged-false-deletion-eviction
• Worktree: /home/user/objectui-issue-7821
• Domain: domain:ui
• File surface: packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx 的 onManageChanged 那一处（约 :343 附近，⛔ 按内容定位不按行号）+ 同目录测试。⛔ 不出这个文件（+ 新增测试）。
• Container & model: 本会话容器 · opus
• Clause-②: no
• Serial constraints cleared: ⚠️ PR fix(app-shell): the Studio package switcher reports its fetch failure instead of swallowing it #7822（卡 app-shell(studio): PackageSwitcher swallows the package-list fetch failure, leaving the raw package id in the top bar #7368）已于 00:30:12Z 合入同一文件 —— 所以从今天的 origin/main 开分支就已经带着它的改动（三态 pkgListState、formatMetadataError 上报、共用 sonner id）。⛔ 不要重做那部分。同 lane 在飞的其余卡落在 examples/schema-catalog/、scripts/check-i18n-call-site-keys.mjs、content/docs/components/basic/text.mdx —— 不相交。

PM 裁定

这一处的病与 #7368 修的三处不同类，所以当时故意没有顺手修

#7368 的三处是「吞掉失败、少了个 toast」。这一处吞掉失败之后产生了一个错误的决策：

onManageChanged 的 catch { /* keep the stale list */ } —— 那句注释对 pkgs 状态成立，对局部 list 不成立：list 初始化成 [] 且一直是 []，于是三行后的 !list.some(...) 恒真，代码走进 // Deleted 分支；当被管理的包正是编辑器下的那一个时，它 navigate 到 /home（list[0] 是 undefined）。

⇒ 一次瞬时 503 就把作者踢出 Studio。 ⭐ 这是「静默降级」升级成「静默做出相反决定」，⛔ 不是同一个修法。

⚠️ 先在今天的 main 上复核这条链的每一环（list 的初始化、!list.some(...) 的位置、// Deleted 分支、/home 的导航），⛔ 不要采信卡片或本裁定 —— #7822 刚改过这个文件。

交付物

区分「刷新失败」与「包真的被删了」，并且失败时⛔ 不做删除推论。

⭐ 具体形状由你按这个文件已有的姿态决定 —— #7822 刚刚在同一文件里落地了 pkgListState: 'loading' | 'failed' | 'loaded' 与 formatMetadataError 上报的共用 sonner id。能复用就复用，⛔ 不要造第二套错误状态机。

⛔ 不要把 .catch 改成 throw（一次 503 不该弄死 Studio 顶栏 —— #7368 的裁定同样适用）。⛔ 也不要引入重试（同样的理由：重几次/退避/放弃后显示什么，都是没人裁过的新策略）。

证据

⭐ 验收是行为的，不是"加了个 if"：让 fetchPackages() 在 onManageChanged 路径上拒绝，断言

1. 不发生导航（作者留在原地）；
2. 失败被上报（走本文件已有的姿态）；
3. 而真的被删时（列表成功返回且不含该包）导航行为不变。

⛔ 第 3 条不能省 —— 只钉前两条，修复可能退化成「永远不导航」，那会把一个真实的删除后残留在一个不存在的包上。

消融：把区分拿掉，第 1 条必须变红并自报其名。变异落盘后自证（hash + 锚点计数翻转），还原走 git checkout HEAD -- <绝对路径> 且在 trap … EXIT INT TERM 里，以状态证明还原。⚠️ trap 只在实现已提交之后才武装 —— 本 lane 在 #7448 上踩过：守卫拒绝 exit 91 时 trap 已触发，把文件静默还原到了未修复的 HEAD。

边界

• Clause-② no：⛔ 不新增导出、不改签名、不改任何门。
• packages/app-shell/src/ 是已发布包的源码 ⇒ 欠 changeset。跑 node scripts/check-changeset-presence.mjs 并原样引用判词。
• ⚠️ 若你发现「正确的恢复目的地」本身有问题（比如写死 /home 而不是声明的落地页）—— 那是 finding(app-shell): app-missing / access-denied 恢复重定向仍写死 /home，应跟随声明的落地页（#7256 裁 B 的后续，先量夹具改动） #7373，⛔ 报回不要顺手改。

---

Generated by Claude Code