雷电芽衣
1c225f6812
ElyMail's window lists accounts and adds Gmail, Microsoft, iCloud (app-specific password), IMAP and POP3 ones; a check logs in to both servers and reports each. Accounts live in the store as JSON with a case-insensitive unique address; secrets go to the keychain. Removal names the cache it deletes, takes the secret first and puts it back when local removal fails. Originals are set aside until commit and restored after a crash. Requests are numbered so late results stay with their own dialog. The account list is keyboard-navigable.
2.8 KiB
FAIL
-
[P1] crates/ely-mail-engine/src/store/accounts.rs:74 — 删除账号逐个永久删除原文，后续失败时只回滚 SQLite，已删除的文件无法恢复。Windows 探针给同一账号存两份不同原文，占住删除顺序中后一份文件；
remove_account报共享冲突，账号和两条消息仍在，但前一份原文已丢失，original报文件不存在。这违背删除失败保留数据、可重试的行为。应让整批原文删除可恢复，任一文件操作或提交失败时恢复之前处理的原文，并补上多文件中途失败的回归测试。复现见.work/C12.5-r1/engine-probe.log。 -
[P1] apps/ely-mail/src/view.rs:120 — 删除确认按钮实际不删除任何账号。钉住的
ConfirmDialog先调用关闭回调，再调用on_confirm；这里关闭时先将mail.removing清空，随后Mail::remove在removing.rs:49直接返回。窗口探针按 Tab、Tab、Enter 确认，日志记录了 confirmed 和 closed，但账号数仍为 1，凭据也没有删除。现有测试直接调用Mail::remove，绕过了此路径。应把待删目标捕获并传给确认操作，使其不依赖关闭时清掉的状态，并通过真实确认按钮测试。复现见.work/C12.5-r1/ui-probe.log。 -
[P2] apps/ely-mail/src/adding.rs:148 — 是否自动填写端口仅按数值是否属于六个惯用端口判断，且修改任一服务器的加密方式都会重写两个端口，无法保留手填值。探针在 IMAP 表单手填收信端口 995，再仅将 SMTP 从 STARTTLS 改成 TLS，收信端口即被静默改为 993。自定义端口的账号因此会检查错误的端点，也与 C12.5 所述“手填的端口不动”不符。应逐字段记录自动值与用户编辑状态，只更新相应服务器尚未手填的端口，并覆盖手填值恰为其他协议惯用端口的测试。复现见
.work/C12.5-r1/ui-probe.log。 -
[P2] apps/ely-mail/src/flow.rs:239 — 保存结果未绑定发起保存的对话框，会清掉后来打开的另一份添加表单。保存账号 A 的后台库操作尚未结束时，用户仍可取消对话框、重新添加并填写账号 B；A 保存完成后无条件执行
mail.adding = None，B 的输入全部消失。探针用存储锁延迟 A 的保存，重开并填写 B 后释放锁，稳定复现。失败回调的halt同样会改写新对话框。应将保存回调绑定其所属对话框；账号列表照常更新，只对仍匹配的表单更新状态或关闭。复现见.work/C12.5-r1/ui-probe.log。 -
[P3] apps/ely-mail/src/mail.rs:1；apps/ely-mail/src/removing.rs:1 — 两条新增模块注释各有 11 个词，超过项目规定的十词上限。运行
python tests/scripts/comments.py会将两处列为失败。应将它们缩短到十词以内。检查输出见.work/C12.5-r1/comments.log。