creation_failed 手动清

手动将 tabSite 表的 creation_failed 字段从时间戳改为 NULL，阻止 Press 在 14 天后自动下架手动迁移的站点。

1. 归属

问题	答案
属于哪个仓库？	不涉及源码。操作的是 Press DB 里的 `tabSite` 表
在容器内路径？	无。通过 `bench execute` 直接改 DB
在构建链的哪一步？	不是构建问题。站点迁移后 Press 状态机写入的失败标记

creation_failed 是什么？

tabSite 表的一个 datetime 字段。当 Agent Job “New Site” 失败时，process_new_site_job_update() 自动写入当前时间戳。

有什么作用？

check_allowed_actions() 检查此字段：非空时只允许 restore 和 drop 操作，阻止所有其他操作。archive_creation_failed_sites() 定时任务检查此字段，非空且超过 14 天的站点自动下架。

和 Agent Job手动标Success 同根因：gottenergy 是手动迁移的，触发了 New Site Job（错误的 Job 类型）→ Job 失败 → Press 写入 creation_failed。

如果走官方流程：调 restore() API → 触发 Restore Site Job（不是 New Site Job）→ Job 正常 Success → creation_failed 永远不会被写入。这个字段根本不会出现。

frappe.db.set_value('Site', 'gottenergy.getgrowth.app', 'creation_failed', None)

效果：Press 不再限制该站点的操作，14 天自动下架定时任务不再匹配到它。

hack。 直接清掉了 Press 状态机设置的保护字段。CLAUDE.md 禁止手动改 DB 状态字段。

站迁移走官方 restore() API → Restore Job 成功 → creation_failed 自然为空。

SolarFlow 部署后 R2 已配好，备份文件上传到 R2，调 restore(files) 即可。不再需要手动灌数据和清 DB 字段。