finding(app-shell): onManageChanged's managed-snapshot refresh swallows a failed read, so the open sheet shows a pre-action record as current

[claude]

Observation

Found while implementing objectui#7881 (fetchFullPackage never reading res.ok), in
the same component, one callback below it. Deliberately not fixed there: that card is
scoped to the lookup behind openManage, and PR #7879's dispatch fenced
onManageChanged off explicitly.

onManageChanged in packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx
runs after every package lifecycle action fired from the PackageDetailSheet (disable /
duplicate / delete / publish / manifest edit). Its tail refreshes the managed
snapshot so an edit shows immediately:

try {
  const fresh = await fetchFullPackage(managedId);
  if (fresh) setManage(fresh);
} catch {
  /* keep the current snapshot */
}

That catch is silent, and the sheet stays open on the record it already had. So when
the refresh fails, the author has just performed a lifecycle action, the sheet reports
nothing, and what they are reading is the pre-action snapshot presented as current —
the same "a read that could not happen is reported as a read that found nothing" family
as objectui#7368, objectui#7821 and objectui#7881, in the one place on this surface that
still swallows.

Two things make it worth a card now rather than before:

• Before objectui#7881 that catch could only ever catch a res.json() rejection — a
  non-JSON body. With res.ok now read, it also catches every 4xx/5xx the endpoint
  serves (401 / 403 / 503 / 500), so the arm it silences got substantially wider.
• Unlike the head of the same callback — which objectui#7821 taught to report through
  formatMetadataError on the shared studio-package-list sonner id and to record
  pkgsErr — this tail reports through nothing at all. The posture already exists three
  lines above it.

Not necessarily the same call

The head of onManageChanged draws an inference from a failed read (deletion or
not), which is why objectui#7821 had to stop it. This tail draws no inference: keeping
the current snapshot on a failed refresh is a defensible degradation, and objectui#7368's
standing ruling is that one 503 must not take the Studio down. The gap is that the
degradation is silent — the author cannot tell a refreshed record from a stale one.
Reporting it on the shared toast id would close that without changing the degradation.

Worth deciding

1. Report on the shared studio-package-list sonner id and keep the stale snapshot —
   cheapest, and reuses the posture already in this callback's own head.
2. Report and mark the sheet's record as stale, so the staleness survives the toast (a
   toast disappears; an open sheet does not).
3. Leave it silent and say so in writing, i.e. record why this one arm is exempt.

Re-check

grep -n "keep the current snapshot" -B 6 packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx

Related, not duplicates: objectui#7368 (the switcher's silence, merged), objectui#7821
(the false-deletion eviction, merged as #7879), objectui#7881 (the lookup, PR #7906).

---

Generated by Claude Code

[claude]

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

• Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
• Branch: claude/issue-7907-manage-snapshot-refresh-swallows
• Worktree: /home/user/objectui-issue-7907
• Domain: domain:ui
• File surface: packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx 里 onManageChanged 的尾部（managed-snapshot 刷新）及其在 packages/app-shell/ 下的测试。⚠️ 若需要新的错误消息键，packages/app-shell/src/views/metadata-admin/i18n.ts 已获批准（finding(app-shell): fetchFullPackage never reads res.ok, so a failed package lookup opens the management sheet on a null package - silently #7881 的先例）——但请在 open_questions 里点名，⛔ 不要只在 gates 段落带过。
• Container & model: 本会话容器 · opus
• Clause-②: no
• Serial constraints cleared: ⚠️ PR fix(app-shell): a failed package lookup is not an empty result (objectui#7881) #7906（卡 finding(app-shell): fetchFullPackage never reads res.ok, so a failed package lookup opens the management sheet on a null package - silently #7881）已于 03:00:53Z 落地 —— 它既是本卡的解锁条件，也是你的工作样板，而且它把本卡这条臂变宽了（见下）。当前 open PR 无一触碰该文件。

⚠️ 先读清楚本卡与 #7881 的关系：#7881 把这条臂变宽了

onManageChanged 有头和尾两段：

• 头 = 包列表刷新 ⇒ finding(app-shell): onManageChanged reads a failed package-list refresh as "the package was deleted" and evicts the author to /home #7821 / PR fix(app-shell): a failed package-list refresh is not a deletion (objectui#7821) #7879 已修（[] 不再当失败初值）；
• 尾 = managed-snapshot 刷新 ⇒ 就是本卡，它静默吞掉失败的 fetchFullPackage，于是生命周期动作之后，已打开的面板把动作前的记录当作最新呈现。

⚠️⚠️ 而 #7881 让它吞得更多了：在 #7881 之前，那个 catch 只能看到 res.json() 的拒绝；现在 fetchFullPackage 会对每一个 401 / 403 / 503 / 500 抛出，所以那条臂现在也吞这些。

⇒ ⭐ 这是「修一个吞错误的缺陷，会让另一个吞错误的地方吞得更多」的实例。请把这句话写进 PR，否则读者会以为 #7906 引入了本缺陷。⛔ 它不是回归 —— 它是被 #7881 变得更容易触发的既有缺陷。

交付物：照 #7906 / #7879 已落地的姿态，⛔ 不要开第三套

读 PR #7906 的 diff 与它的落地记录，那是同一文件同一族的工作样板。原则一字不改地适用：

• 失败走本文件已有的 app-shell(studio): PackageSwitcher swallows the package-list fetch failure, leaving the raw package id in the top bar #7368 姿态 —— formatMetadataError + 共享的 studio-package-list sonner id。⛔ 不要开第二台错误状态机：修「吞错误」时最容易顺手引入第二套上报机制，然后两套各自漂移。
• ⚠️ pkgsErr 槽写不写，先量再决定。finding(app-shell): fetchFullPackage never reads res.ok, so a failed package lookup opens the management sheet on a null package - silently #7881 裁定 A（不写），理由是实测的文件内规则：pkgsErr 恰恰写在 pkgs 被写的地方，而 openManage 从不写 pkgs。⭐ 但本卡不同 —— onManageChanged 确实写 pkgs（它就是那个刷新）。所以 finding(app-shell): fetchFullPackage never reads res.ok, so a failed package lookup opens the management sheet on a null package - silently #7881 的裁定未必适用：自己量这条臂写不写 pkgs，并据此判断，把理由写出来。⛔ 不要照抄 A，也不要照抄 B。

⛔ 先量响应形状（#7881 已经把这条路铺好了）

#7881 实测出：GET /api/v1/packages 的失败只有一种信封（success:false + error:{code,message}，401/403/503/500），且信封自己的 success 不是第二个可判定位（它就是 !res.ok 的复述）；5xx 波段平台扣下生产者散文换成通用文案 ⇒ error.code 是唯一有区分度的词。

⚠️ 但本卡的尾部读的是 fetchFullPackage，路径可能不同。 ⛔ 不要采信上面这段：自己量这条臂上的真实响应形状（HTTP 状态、body 结构、有没有 error/message），并说明你的处理覆盖了哪几种、漏了哪几种。若发现不止一种形状，全部报出。

⛔ 证据形状：照 #7906 的消融，而且要排除退化解

#7906 的消融之所以有说服力，是因为阴性对照在撤销修复后仍绿 ⇒ 新钉子不是复述既有断言，而且一个「只把面板关掉」的假修复过不了那个文件。

本卡照做：

• 改前：生命周期动作后让 snapshot 刷新失败（用上面量到的形状），证明面板仍呈现动作前的记录、且什么都没报；
• 改后：同一输入下失败被报出，且面板不再把陈旧记录当作最新（⚠️ 具体表现你来定——是关闭、是显示陈旧标记、还是别的——并说明为什么那是正确的行为，⛔ 不要默认「关掉就行」）；
• ⭐ 阴性对照：一次成功的 snapshot 刷新，改前改后都正常更新面板 —— ⛔ 否则你可能只是把刷新弄坏了；
• ⭐ 再加一条排除退化解的对照：一个「只是把面板关掉」的假修复必须过不了你的钉子。撤销修复时，哪些钉子该红、哪些该绿，请先写下预测再运行（finding(plugin-list): ObjectGallery carries the same pre-gate shape objectui#7895 just removed from ObjectTimeline — 2 find calls per load #7903 的席位这么做了，5 红 2 绿分毫不差；ObjectTimeline never took the settled-schema gate — 2 find calls and a second paint per load, the last unconverted member of #6482 / #7225 #7895 预测 2 实测 4，如实报出而未调平 —— 两种都是诚实的）。
• 突变先在磁盘上证明落盘（锚计数 + blob hash），恢复由状态证明（git diff HEAD 空 + blob 回到 HEAD blob），⛔ 不用退出码。

边界

• ⛔ /home 硬编码不是本卡的 —— 归 finding(app-shell): app-missing / access-denied 恢复重定向仍写死 /home，应跟随声明的落地页（#7256 裁 B 的后续，先量夹具改动） #7373。fix(app-shell): a failed package-list refresh is not a deletion (objectui#7821) #7879 与 fix(app-shell): a failed package lookup is not an empty result (objectui#7881) #7906 都逐字节保留了它，你也保留。
• ⛔ 不动 onManageChanged 的头部（fix(app-shell): a failed package-list refresh is not a deletion (objectui#7821) #7879 已修）、不动 openManage（fix(app-shell): a failed package lookup is not an empty result (objectui#7881) #7906 刚修）。
• changeset： app-shell 是已发布包且改 src/，真实用户可见修复 ⇒ 大概率 patch。⛔ 不要用我这句猜测：跑 node scripts/check-changeset-presence.mjs，以判词为准并逐字贴出。今天检查器已八次推翻推理，其中两次是本席的。
• Clause-② = no：不加导出、不改签名、不动任何 gate。若判断错了，停下报回。

---

Generated by Claude Code