跨端: 补附件区（两端一直都有这个功能，我上次误判成"死代码"）+ 修两个真 bug
══ ① 更正我 2026-09-19 的一个**错误结论**（已写进 docs/DEBTS.json 留档） 那天我审计后写下：`GET /me/mail/inbox` 的回包**既没有 `attachments` 也没有 `has_attachments`** ⇒ `MailList.tsx:261` 的 `mail.attachments?.length ?? 0` 恒为 0、WebUI 那个 📎 是**死代码**。并据此在鸿蒙侧**有意不抄**这个标记。 **这个结论是错的**，错在取证方法：我**只看了一封没有附件的邮件**， 看到 key 不在，就断言服务端从不返回它。事实： · 服务端 `GetInbox`（`mail.go:586`）**明确调了 `fillAttachments`**，注释还写着 理由：「Agent 靠收件箱列表得知有哪些附件可下载，否则它不知道该调 attachment_id」 · `Mail.Attachments` 的 tag 带 **`omitempty`** ⇒ **没有附件的邮件根本不输出这个 key** 实测 `limit=200`（96 封）：带 `attachments` 的 **2 封**，正是真有附件那两封。 ★ 教训：**`omitempty` 字段的"缺失"不等于"服务端不返回"**。 判「某字段有没有」必须拿**确实有值的那条**去验，而不是拿一条恰好为空的数据。 这与同一天那个白屏崩溃（`session_workspace` 缺失 → `undefined` → 抛） 是**同一个坑的两面** —— 那天是"缺失 → 客户端崩"，今天是"缺失 → 我误判成不返回"。 ══ ② 补附件区（鸿蒙原来完全没有） · `model/Attachment.ts`（新）—— `formatSize` / `attachmentLabel`，纯逻辑无 SDK 依赖， 逐字对齐 WebUI `api/client.ts:390`（三档 + 保留一位小数）。 · `MailApi.downloadAttachment` —— 走 `getBytes`（不是 `get<T>`：后者假定 JSON， 取二进制会炸；壁纸当初踩过）。 · `IcsFile.saveBinaryFile` —— 与既有 `saveIcsText` 同一套流程，只是写 `ArrayBuffer`。 · `MailDetailPage` 正文之后渲染附件清单（回形针 + 文件名 + 大小 + 下载）， 位置/形态对齐 WebUI `Attachments.tsx`（无附件时**整块不渲染**）。 · 列表行的 📎 + 数字（`attach_count`，与 `cc_count` 同形状派生）。 ══ ③ 顺带撞出并修掉两个**真 bug** **bug A（差一点就是 94/96 必崩）**：我第一版写 `mail.attachments.length` —— 而 `Attachments` 带 `omitempty`，96 封里只有 2 封有这个 key ⇒ 其余 94 封是 `undefined` ⇒ `.length` 抛。**与当天早些时候那个白屏崩溃是同一个坑， 我刚修过、还在 `Models.ets` 里写了一大段注释，然后加新字段时照踩。** ⇒ 说明"记住别这么写"不管用，要在每个真正读的地方把 `?? []` 写出来。 **bug B（潜在白屏）**：`PermissionTab` 读 `req.session_alias` —— 而服务端 `PermissionRequest` struct **根本没有这个字段**（`models.go:239-255`）， `ListPendingPermissionsFor` 的 SELECT 也没查它，WebUI 的类型里同样没有。 它是我照"授权卡总得显示会话名"的直觉加出来的。⇒ 恒 `undefined`， 一旦有待办就抛。**一直没暴露只因为当前待办数一直是 0**（实测 `{"requests":[]}`）。 ⇒ 改成服务端确实有的 `agent_name`，并**删掉那个字段声明**： 让误用变成**编译错**，而不是运行时白屏。 同样是 `body_preview`（`omitempty`，值是 `Body` 的截断）—— 空正文 ⇒ 空串 ⇒ 服务端省略 key ⇒ `undefined.length` 抛。那批 96 封恰好都有正文， 所以"看起来没问题"——那正是这个坑的形态。已加 `?? ''`。 ══ ④ 新判据：`omitempty` 字段的读法（形状，不是实例） 从 `server/internal/models` **算出**"只以 omitempty 形式出现过"的字段名 （不在判据里手抄名单），再扫鸿蒙侧对它们的裸成员调用。 ★ 关键：**不能按字段名一刀切** —— 我第一版就是这么写的，报了 6 处、4 处误报： `session_alias` 在服务端有**两个**声明（`Mail` 上带 omitempty、`repo.Contact` 上不带）， 鸿蒙那 4 处读的全是 `Contact` ⇒ 恒有值、不是 bug。 ⇒ 只扫"从未不带 omitempty 出现过"的名字，那 4 处自动排除。 已逐个核实 4 处豁免（每条都写了取证理由，不是"看着像就放过"）。 变异验证：把 `?? []` 去掉 → 判据转红，且**正是**报 `MailStore.ets: mail.attach_count = mail.attachments.length`。 ══ ⑤ 数据路径已实测（模拟器） 临时把 `INBOX_PAGE_SIZE` 提到 200（因为有附件那两封在下标 51/52， 默认 limit=50 **根本取不到** —— 这也解释了为什么之前一直没发现）， 加临时 hilog 后拿到： AttProbe: mail=531a1629-… attach=1 AttProbe: mail=b68cbbe8-… attach=1 正好是那两封。验完已撤掉探针、`INBOX_PAGE_SIZE` 恢复 50。 ══ ⚠️ 本轮**未能**完成设备端视觉验收 模拟器已卡死（`hdc` 能连上但 `shell` 超时；进程 152% CPU、已跑 32 小时）， 导致套件里的设备判据各跑 836 秒后失败（"要能拉起应用"）。 主机可用内存只剩 ~3.7GB。附件区的**渲染**（清单外观、下载落盘） 尚未在设备上看过 —— 待模拟器恢复后补。
This commit is contained in:
@ -827,21 +827,41 @@ struct InboxTab {
|
||||
* 在列表里看不出任何区别，得点进去才知道。而 `cc_list` 服务端一直有返回
|
||||
* （实测回包字段列表里有），只是 `MailLike` 接口漏了这个字段。
|
||||
*
|
||||
* ★★ **有意不抄附件标记**（WebUI 那个 `attachCount`）：核对服务端实测回包，
|
||||
* 列表接口既没有 `attachments` 也没有 `has_attachments`
|
||||
* （`MailList.tsx:351` 的 `mail.attachments?.length ?? 0` 在列表里**恒为 0**
|
||||
* —— 它在 WebUI 上也是个从不出现的死标记）。
|
||||
* 照抄一个不工作的东西，只会让鸿蒙多一处"看起来有、永远不亮"的代码。
|
||||
* ⇒ 要显示附件数得先让**服务端**在列表回包里带上它；那是独立的一件事，
|
||||
* 不是这里顺手能补的。
|
||||
* ── 附件标记（WebUI `MailList.tsx:351` 那个回形针 + 数字）──
|
||||
*
|
||||
* 有条件才画：没有抄送时不占位，否则每行都多一片空白。
|
||||
* ★★ 2026-09-20 **更正我 2026-09-19 的一个错误结论**。
|
||||
*
|
||||
* 那天我在这里写的是「**有意不抄**附件标记」，理由是我"实测"列表接口
|
||||
* 既没有 `attachments` 也没有 `has_attachments`，所以 WebUI 那个 📎
|
||||
* 在列表里恒为 0、是死代码。
|
||||
*
|
||||
* **那个结论是错的**，错在取证：我只看了一封**没有附件**的邮件，
|
||||
* 看到 key 不在就断言服务端从不返回它。而
|
||||
* · 服务端 `GetInbox`（`mail.go:586`）**明确调了 `fillAttachments`**，
|
||||
* 注释还写着理由：「Agent 靠收件箱列表得知有哪些附件可下载，
|
||||
* 否则它不知道该调 attachment_id」；
|
||||
* · `Mail.Attachments` 的 tag 带 **`omitempty`** ⇒
|
||||
* **没有附件的邮件根本不输出这个 key**。
|
||||
* 实测 `limit=200`（96 封）：带 `attachments` 的 2 封，正是真有附件那两封。
|
||||
*
|
||||
* ⇒ WebUI 那个 📎 **不是死代码**，鸿蒙这次补上它。
|
||||
*
|
||||
* 有条件才画（两端同口径）：没有附件/抄送时不占位，否则每行都多一片空白。
|
||||
*/
|
||||
if (mail.cc_count > 0) {
|
||||
Text('抄送 ' + mail.cc_count)
|
||||
.fontSize(10).fontColor(Theme.textSubtleFor())
|
||||
.margin({ top: 3 })
|
||||
Row({ space: 8 }) {
|
||||
if (mail.attach_count > 0) {
|
||||
Row({ space: 2 }) {
|
||||
AmIcon({ iconName: 'paperclip', iconSize: 10, iconColor: Theme.textSubtleFor() })
|
||||
Text(mail.attach_count.toString())
|
||||
.fontSize(10).fontColor(Theme.textSubtleFor())
|
||||
}
|
||||
}
|
||||
if (mail.cc_count > 0) {
|
||||
Text('抄送 ' + mail.cc_count)
|
||||
.fontSize(10).fontColor(Theme.textSubtleFor())
|
||||
}
|
||||
}
|
||||
.margin({ top: 3 })
|
||||
}
|
||||
.layoutWeight(1).height('100%')
|
||||
.alignItems(HorizontalAlign.Start)
|
||||
@ -1001,7 +1021,15 @@ struct SentTab {
|
||||
.maxLines(1).textOverflow({ overflow: TextOverflow.Ellipsis })
|
||||
.margin({ top: 4 })
|
||||
|
||||
if (mail.body_preview.length > 0) {
|
||||
/*
|
||||
* `?? ''` 不能省：服务端 `BodyPreview` 带 `omitempty`
|
||||
* （`models.go:183`），而它的值就是 `Body`（≤200 字截断）——
|
||||
* **空正文的邮件 → 预览是空串 → 服务端整个 key 都不输出**
|
||||
* ⇒ `undefined.length` 抛 TypeError。
|
||||
* 实测那批 96 封恰好都有正文，所以"看起来没问题"—— 那正是这个坑的形态：
|
||||
* 拿一批恰好非空的数据是验不出它的（见 Models.ets 顶部那段教训）。
|
||||
*/
|
||||
if ((mail.body_preview ?? '').length > 0) {
|
||||
Text(mail.body_preview)
|
||||
.fontSize(11).fontColor(Theme.textMuted)
|
||||
.maxLines(2).textOverflow({ overflow: TextOverflow.Ellipsis })
|
||||
@ -1275,7 +1303,24 @@ struct PermissionTab {
|
||||
.fontSize(13).fontWeight(FontWeight.Bold).fontColor(Theme.textPrimary)
|
||||
.maxLines(1).textOverflow({ overflow: TextOverflow.Ellipsis })
|
||||
.layoutWeight(1)
|
||||
Text(req.session_alias.length > 0 ? req.session_alias : '(未命名会话)')
|
||||
/*
|
||||
* ★★ 2026-09-20 修：**这里原来读的是一个不存在的字段**。
|
||||
*
|
||||
* `req` 是 `PermissionRequest`，而服务端那个 struct
|
||||
* （`models.go:239-255`）**没有 `session_alias`** ——
|
||||
* `repo.ListPendingPermissionsFor` 的 SELECT 也没查它。
|
||||
* WebUI 的类型里同样没有（`types/index.ts:233` 只有 `session_id`/`agent_name`）。
|
||||
*
|
||||
* ⇒ `req.session_alias` 恒为 `undefined`，
|
||||
* 一旦有待办，`.length` 当场抛 TypeError（整页白屏）。
|
||||
* 这个 bug **一直没暴露只是因为当前待办数一直是 0** ——
|
||||
* 实测 `/permission/pending` 返回 `{"requests":[]}`。
|
||||
*
|
||||
* 改成服务端**确实有**的 `agent_name`（授权请求一定由 Agent 发出，
|
||||
* 这是卡片上最有辨识度的一格）。
|
||||
* 与 WebUI 同口径：那边授权卡标题也只显示 Agent 与问题，不显示会话别名。
|
||||
*/
|
||||
Text(req.agent_name.length > 0 ? req.agent_name : '(未知 Agent)')
|
||||
.fontSize(10).fontColor(Theme.accentFor())
|
||||
}
|
||||
.width('100%')
|
||||
|
||||
Reference in New Issue
Block a user