settings.yaml legacy import: file is renamed before sections are imported, so a failed import silently loses all settings

[gysyl]

Version

0.1.7-alpha.1 (dsh-v0.1.7-alpha.1)

Summary

The one-time settings.yaml import introduced in 0.1.7 renames the file to settings.yaml.imported before attempting to import any section. If the running composition cannot accept one or more sections on that boot (e.g. the first boot after upgrade has a plugin entry that fails to activate or stays pending), every rejected section is only logged as a warning, the original file is already gone, and the import never retries — because the file no longer exists on the next boot.

Net effect: a transient first-boot problem turns into permanent, silent loss of the entire settings.yaml (model providers, default model, permission presets, plugin settings), with no recovery path other than manual reconstruction.

Reproduction

1. On 0.1.6, have a populated settings.yaml (e.g. LLM provider definitions, agent default model, permission presets).
2. Upgrade to 0.1.7-alpha.1 such that the first boot of a profile has any plugin entry that fails to activate or stays pending (in our case a third-party plugin waiting on a service removed in 0.1.7).
3. Start dsh web. The loader settles (with the failed entry), importLegacyDocument() runs, the file is renamed immediately, and each update() for the settings sections throws ("No configurable plugin entry ...") because the composition is not fully addressable.
4. Result: sections are rejected with warnings in server logs only; settings.yaml is already renamed. Restarting does not retry — the file is gone.

Observed on 0.1.7-alpha.1 / Linux / dsh web. The behavior matches the code comment in @deepseek-ai/dsh-settings ("The document is renamed before the first write, so a partial import never repeats") — but that ordering converts a partial failure into an unrecoverable full loss.

Root cause

importLegacyDocument() performs rename(path, imported) before the per-section import loop. The rename is unconditional; import success is not.

Expected behavior / suggested fix

Import first, rename last: keep the original settings.yaml in place when any section fails (rejected sections stay ignored on disk), and retry the import on the next boot — only drop/rename the file once every section has been accepted. That single ordering change makes the one-time import self-healing instead of destructive.

(Optionally also surface a visible notice in the web UI when sections are rejected, instead of server-log-only warnings.)

---

中文版（附）

标题

settings.yaml 一次性导入：先改名后导入，导入失败即静默丢失全部设置

摘要

0.1.7 的 settings.yaml 一次性导入在执行任何 section 导入之前就把文件改名为 settings.yaml.imported。若该次启动组合树中有插件条目激活失败或 pending，各 section 的导入会被拒绝（仅服务端日志 warn），而原文件已被收走，下次启动也不会重试——文件已不存在。

后果：一次瞬时的首启动异常 → 整个 settings.yaml 永久静默丢失（模型 provider、默认模型、权限预设、插件设置），除手工重建外无恢复路径。

复现

1. 0.1.6 上有一份内容完整的 settings.yaml；
2. 升级到 0.1.7-alpha.1，且某 profile 首次启动时有插件条目激活失败/pending（实测：某第三方插件等待一个 0.1.7 已移除的服务）；
3. 启动 dsh web：loader 结束后 importLegacyDocument() 立即改名，随后各 section update() 因组合不可寻址抛出 "No configurable plugin entry"；
4. 结果：section 全拒（仅日志）、settings.yaml 已被改名、重启不重试。

根因

importLegacyDocument() 的 rename(path, imported) 在按 section 导入循环之前无条件执行，改名与导入成败无关。

期望行为 / 修复建议

先导入、后改名：任何一个 section 失败时保留原 settings.yaml（被拒 section 留在原文件中），下次启动重试导入；全部 section 接受后才收走文件。仅这一处顺序调整即可让一次性导入从「破坏性」变为「自愈性」。

（可选：section 被拒时在 Web UI 给出可见提示，而非仅服务端日志。）

[xiaoyuyu6420]

机制分析完全成立——补一条给已经中招用户的即时恢复动作，因为你报告里的机制恰好也给出了它：

改名（rename）不销毁内容——settings.yaml.imported 就是你的原文件。把它拷回 settings.yaml（或直接改名回来），下次启动时导入会重新尝试；如果那次启动环境干净（插件都能激活），各 section 就会正常落位。也就是说「永久丢失」其实是「永久不重试」——数据一直在 .imported 里，可以救。

两个配套建议：

1. 升级到 0.1.7 前先拷一份 settings.yaml——在官方修掉「先改名后导入」的顺序问题之前，这是唯一的预防手段；
2. 恢复后如果发现个别 section 还是没进（比如某个插件仍未激活导致它再次被拒），对着启动日志里的 warning 行核对是哪个 section，先把对应插件修好再重启一次。

你这个「导入成功性与文件改名顺序」的发现值得进 #6520 那份未修复清单——它是和迁移拒绝同一家族的「升级流程自己制造数据风险」问题，而且修复成本极低（先导入后改名，或失败时回滚改名）。

[gysyl]

感谢补充，完全正确——rename 保留的是原文件，「永久丢失」应为「永久不重试」，我们实际就是从 settings.yaml.imported 手工恢复的。

同意收录 #6520 的未修复清单，修复建议维持「先导入后改名：任一 section 失败保留原文件、下次启动重试」。