尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

OpenCreator 定时任务专属会话发布、迁移与回滚运行手册

OpenCreator 定时任务专属会话发布、迁移与回滚运行手册 OpenCreator 定时任务专属会话发布、迁移与回滚运行手册【免费下载链接】OpenCreatorFormerly KrillinAI. Open-source AI workspace for creators, powered by Codex. Create videos, images, voice, avatars, translations, and edits with Agents in one place.项目地址: https://gitcode.com/GitHub_Trending/kr/OpenCreator导读本文是 OpenCreator原 KrillinAI基于 Codex 的开源 AI 创作工作区中一个 Schedule 对应一个长期 OpenCreator Thread定时任务模型的发布、迁移与回滚运行手册。它面向需要升级或回滚生产环境的开发与运维人员完整覆盖旧 SQLite Schema 向前迁移、旧活动 Schedule 专属任务 Thread 补齐、发布前后数据不变量检查、应用代码回滚与新版恢复、以及真实 Codex / 浏览器 / 性能 / Desktop Host 验收边界。读完本文你将掌握该模型升级的完整安全约束、自动化演练命令、可复制的生产升级与回滚流程以及每条命令背后的源码级实现依据。本文主体内容来自仓库中的发布运行手册 docs/operations/2026-07-15-scheduled-task-dedicated-thread-release-runbook.md并结合 apps/daemon/src/storage/migrations.ts、apps/daemon/src/scheduler/coordinator.ts、apps/daemon/src/startup.ts、apps/daemon/scripts/verify-scheduled-task-upgrade.ts 及对应单元测试做了源码级验证与扩充。1. 背景与适用范围在旧模型中定时任务Schedule触发时在会话Thread之外直接产生 Run新版改为一个 Schedule 长期绑定一个专属 OpenCreator Threadpurpose schedule_task自动执行与用户在任务会话内的手动消息都进入同一个 Thread形成完整闭环。本文档适用于该模型升级的发布全过程覆盖六条主线旧 SQLite Schema 向前迁移旧活动 Schedule 补齐专属任务 Thread绑定修复binding repair发布前后数据不变量检查应用代码回滚和新版恢复真实 Codex、浏览器、性能与 Desktop Host 验收边界。迁移的总体原则是只增加字段、表和索引并把旧parallel并发策略转换为queue回滚时不得删除新增字段、索引、任务 Thread、历史 Run、通知 outbox 或 Codex session。2. 安全约束升级的前提红线手册在操作细节之前先定义了 6 条安全约束任何一条被破坏都会导致数据风险必须先停止 Web、daemon 和 Scheduler再复制 Runtime 数据。确保没有进程继续写入 SQLite含 WAL/SHM 文件。必须备份整个.runtime/或OPENCREATOR_DATA_DIR不能只复制app.sqlite——Run 日志、附件、托管工作区都在数据目录中。不得直接在用户唯一数据库上试跑迁移先使用脱敏副本或仓库内置临时演练见第 3 节。不得通过删列、删 Thread、合并 Codex session 或修改历史 Run 实现降级。Scheduler 只能在 Schema 迁移、ensureBindings()和旧会话分类完成后启动否则可能在绑定缺失状态下触发任务。绑定修复失败的 Schedule 会被禁用并清空next_run_at必须先处理失败记录再放量。其中约束 6 在源码中有精确对应协调器的recordBindingRepairFailureTransaction会在修复抛错时把 Schedule 置为enabled false、nextRunAt null并写入operation binding_repair_failed、status failed的操作记录见 coordinator.ts。3. 发布前自动演练仓库内置了一套完全离线的演练脚本它只在系统临时目录创建 SQLite绝不读取.runtime/app.sqlite。在仓库根目录运行pnpm release:verify-scheduled-task-upgrade该命令实际由根package.json转发到 daemon 包release:verify-scheduled-task-upgrade: pnpm --filter opencreator/daemon verify:schedule-upgrade最终执行 apps/daemon/scripts/verify-scheduled-task-upgrade.ts。脚本依次验证 9 项内容旧schedules、threads、runs、schedule_operations可无损迁移旧parallel全部转换为queue每条活动 Schedule 只补一个schedule_taskThreadSchedule 与 Thread 的名称、项目、Profile、模型、推理强度和 Sandbox 一致两条发布 SQL 不变量缺失/重复绑定、配置偏差、parallel归零通过第二次ensureBindings()不再创建 Thread幂等旧代码风格的列清单仍能读取升级后的数据库回滚兼容旧孤立 Schedule Run、已删除 Schedule 和历史操作不被删除恢复新版代码后再次迁移与修复仍保持幂等。成功时末行输出Scheduled task upgrade and rollback rehearsal passed.需要保留临时数据库排查时可运行pnpm --filter opencreator/daemon verify:schedule-upgrade -- --keep--keep会在输出中打印临时数据库路径脚本中mkdtempSync(join(tmpdir(), opencreator-schedule-upgrade-))默认结束后rmSync清理。3.1 演练脚本的源码结构脚本用better-sqlite3手工构造一个旧版数据库createLegacyDatabase其中包含3 条 Schedulesch_legacy_parallelconcurrency_policy parallel活动、sch_legacy_queuequeue活动、sch_legacy_deleteddeleted_at非空已删除1 个普通会话 Threadthread_existing_conversation1 条孤立 Schedule Runrun_legacy_orphancreated_by schedule且thread_id IS NULL1 条历史操作schedule_operations。随后脚本以真实生产入口打开数据库openRuntimeDatabase触发向前迁移构造协调器调用ensureBindings()两次再以旧版列清单只读重开验证回滚兼容最后再次打开新版验证恢复幂等。整个过程的所有断言与手册第 4.3 节的不变量 SQL 完全一致见 verify-scheduled-task-upgrade.ts。4. 生产升级4.1 停止与备份先停止当前 Web、daemon 和任何独立 Scheduler 进程确认没有进程继续写入 SQLite 后执行export OPENCREATOR_DATA_DIR${OPENCREATOR_DATA_DIR:-$PWD/.runtime} export RELEASE_BACKUP$PWD/backups/runtime-before-schedule-thread-$(date %Y%m%d-%H%M%S) mkdir -p $(dirname $RELEASE_BACKUP) cp -R $OPENCREATOR_DATA_DIR $RELEASE_BACKUP随后记录备份路径、应用提交、Codex CLI 版本和数据库摘要git rev-parse HEAD codex --version sqlite3 $OPENCREATOR_DATA_DIR/app.sqlite SQL SELECT sqlite_version() AS sqlite_version; PRAGMA user_version; SELECT COUNT(*) AS schedule_count FROM schedules; SELECT COUNT(*) AS active_schedule_count FROM schedules WHERE deleted_at IS NULL; SELECT COUNT(*) AS thread_count FROM threads; SELECT COUNT(*) AS orphan_schedule_run_count FROM runs WHERE created_by schedule AND thread_id IS NULL; SQLPRAGMA user_version当前可能为0仓库迁移并不依赖 user_version 递增因此发布记录还必须包含应用提交和 Schema 列清单sqlite3 $OPENCREATOR_DATA_DIR/app.sqlite \ PRAGMA table_info(schedules); PRAGMA table_info(threads);4.2 启动新版按部署方式启动新版 daemon或开发态pnpm web:dev。生产入口会按固定顺序执行对应 startup.ts 的prepareSchedulerStartup及生产服务器装配打开 SQLite - 执行向前 Schema 迁移 - ensureBindings() - 分类旧 Schedule session - 注册 API - 启动 Scheduler如果启动日志或 API 显示绑定修复失败立即停止新版不要让 Scheduler 继续触发任务。4.3 升级后不变量SQL 检查清单以下四条 SQL 是发布后必须全部通过的硬性检查演练脚本对同样 SQL 做了断言活动 Schedule 缺少绑定的数量必须为0SELECT COUNT(*) AS missing_active_bindings FROM schedules WHERE deleted_at IS NULL AND thread_id IS NULL;活动 Schedule 重复绑定必须返回空集idx_schedules_thread_id唯一索引在数据库层面兜底见 migrations.tsSELECT thread_id, COUNT(*) AS binding_count FROM schedules WHERE deleted_at IS NULL GROUP BY thread_id HAVING COUNT(*) 1;任务配置偏差必须为0Schedule 与 Thread 的名称、目录、Profile、模型、推理强度、Sandbox 完全对齐SELECT COUNT(*) AS configuration_mismatches FROM schedules AS schedule LEFT JOIN threads AS thread ON thread.id schedule.thread_id WHERE schedule.deleted_at IS NULL AND ( thread.id IS NULL OR thread.purpose schedule_task OR thread.title IS NOT schedule.name OR thread.cwd IS NOT schedule.cwd OR thread.canonical_cwd IS NOT schedule.canonical_cwd OR thread.profile IS NOT schedule.profile OR thread.model IS NOT schedule.model OR thread.reasoning IS NOT schedule.reasoning OR thread.sandbox IS NOT schedule.sandbox );绑定修复失败记录必须为空若非空对应 Schedule 应保持禁用SELECT schedule_id, error_code, error_message, created_at FROM schedule_operations WHERE operation binding_repair_failed ORDER BY created_at DESC;对比升级前后还需确认Schedule 总数和已删除 Schedule 数量不得减少新增任务 Thread 数量应等于需要修复的活动 Schedule 数量旧孤立 Schedule Run 数量不得减少parallel数量必须为0再次重启新版后不得新增第二批任务 Thread。4.4 底层迁移与修复的实现Schema 层的改动集中在 migrations.ts为threads增加purpose列默认conversationL622为schedules增加thread_id列L644为schedule_operations增加actor_type、actor_run_id列L645-L646将存量concurrency_policy parallel全部更新为queueL663-L667创建唯一部分索引idx_schedules_thread_idWHERE thread_id IS NOT NULL AND deleted_at IS NULL从数据库层杜绝一个 Thread 被多个活动 Schedule 复用L699-L701。绑定修复由协调器的ensureBindings()实现coordinator.ts遍历全部 Schedule对threadId为空、或所引 Thread 不存在 /purpose不是schedule_task/ 状态非active的记录在事务内新建schedule_taskThread 并回填thread_id同时写入binding_repair操作记录actorType migration失败则走binding_repair_failed分支禁用该 Schedule。返回{ scanned, repaired, failed, unchanged }四元组供发布日志记录。queue并发策略的运行期行为见 service.ts当 Thread 已有活动 Run 时skip策略直接跳过并记录skip_concurrencyqueue策略则置pending_trigger并通过queue_trigger排队在活动 Run 结束后由队列定时器以run_queued触发——这就是同一任务连续立即执行两次第二次排队或跳过不并行的底层机制。源码还保留了parallel的兼容分支L303-L308但迁移后理论上不会再遇到。5. 灰度检查至少完成以下 8 项检查后再扩大使用范围手动创建任务后立即进入返回的threadId同一任务连续立即执行两次第二次排队或跳过不并行自动执行和用户在任务会话内发送消息都进入同一 Thread暂停、恢复、编辑和删除同步更新已安排、侧栏任务和任务会话头部成功、失败和待审批通知都携带正确的threadId/runId/approvalId模拟 Codex resume 失败后 OpenCreator Thread 不变底层 Codex thread 可以轮换桌面和移动视口无旧会话残留、横向溢出或控制台新增错误受支持的原生 Desktop Host 在页面关闭后仍能消费 outbox 并打开正确深链接。需要特别说明的是仓库本身不包含真实原生 Desktop Host。仅完成 outbox、Bridge 契约和 harness 验证时必须把第 8 项记录为BLOCKED_ENV不能写成实机通过——这是本手册对事实边界的明确要求。6. 应用代码回滚6.1 回滚步骤停止新版 Web、daemon 和 Scheduler保留升级后的 Runtime 数据不删除任何新增列、索引、Thread、Run 或 Codex session回滚应用代码或部署旧版本使用旧版只读取旧列确认 Schedule、Thread 和 Run 仍可读取明确告知用户旧版本会恢复旧任务行为不再提供专属任务会话完整闭环如果需要恢复新版停止旧版后重新部署新版并再次执行第 4.3 节的全部不变量。SQLite 允许旧查询忽略新增列旧SELECT列清单不引用新列即可因此代码回滚的目标是恢复旧应用而不是把数据库破坏性降级。演练脚本中LEGACY_SCHEDULE_COLUMNS/LEGACY_THREAD_COLUMNS/LEGACY_RUN_COLUMNS三份旧版列清单就是对这一点的直接验证verify-scheduled-task-upgrade.ts。6.2 何时使用备份恢复只有在迁移启动前后立即失败、且确认备份后没有任何有效新写入时才能考虑整目录恢复。恢复必须同时覆盖 SQLite、WAL/SHM、Run 日志、附件和托管工作区。如果新版已经产生有效任务 Thread、Run、审批或通知不得用旧备份覆盖应保留数据并通过代码回滚或前向修复处理。7. 发布门禁完整的发布门禁命令如下与根 package.json 中定义的脚本一一对应pnpm test pnpm release:verify-scheduled-task-upgrade pnpm typecheck pnpm build pnpm e2e OPENCREATOR_PERFORMANCE_RESULTS_REQUIRED1 pnpm perf:check OPENCREATOR_RUN_REAL_CODEX_SMOKE1 \ pnpm --filter opencreator/daemon test -- \ --poolforks --maxWorkers1 \ test/smoke/real-codex-smoke.test.ts git diff --check其中perf:check执行 scripts/check-performance-baseline.mjs与 docs/performance 下的基线对比。门禁的附加要求构建警告只有在仍低于仓库固化体积预算时才允许发布真实 Codex smoke 必须记录实际 Codex 版本和 14 个场景结果对应 test/smoke/real-codex-smoke.test.ts因为真实 Codex 是串行资源smoke 必须以--poolforks --maxWorkers1单 worker 运行。8. 2026-07-15 演练基线仓库临时数据库演练结果来自 verify-scheduled-task-upgrade.ts 的一次实际运行输出指标迁移前迁移后Schedule 总数33活动 Schedule22已删除 Schedule11Thread 总数13schedule_taskThread02旧孤立 Schedule Run11缺失活动绑定不适用0重复活动绑定不适用0配置偏差不适用0剩余parallel10首次绑定修复结果为scanned2, repaired2, failed0, unchanged0第二次ensureBindings()与代码回滚兼容读取后的新版恢复均为repaired0, failed0, unchanged2证明修复操作天然幂等——这正是再次重启新版后不得新增第二批任务 Thread这一不变量能成立的原因。9. 配套测试与验证入口除演练脚本外仓库还提供以下与本主题强相关的验证资产可结合阅读test/unit/scheduler-binding-repair.test.ts覆盖一次修复、二次幂等以及单条失败禁用、其余继续修复两个核心场景断言修复后 Thread 的title/cwd/profile/model/reasoning/sandbox/status/purpose与 Schedule 完全一致失败记录携带errorCode/errorMessagetest/unit/startup.test.ts验证prepareSchedulerStartup的启动顺序ensureBindings()先于会话分类test/unit/protocol-shape.test.ts确认binding_repair_failed等操作类型在协议层可见。结语一个 Schedule 对应一个长期 OpenCreator Thread的升级本质上是增量迁移 幂等修复 只读回滚的组合Schema 只增不改ensureBindings()可反复执行旧代码可以无痛读取升级后的数据库新版恢复也不产生重复 Thread。发布者只要严格遵循先停服务、整目录备份、临时库演练、启动前修复、四 SQL 不变量、灰度 8 项检查这条主线即可安全地在生产环境完成该模型的发布与回滚。手册中所有命令与 SQL 均可直接复制执行并能在本仓库源码与测试中找到一一对应的实现证据。【免费下载链接】OpenCreatorFormerly KrillinAI. Open-source AI workspace for creators, powered by Codex. Create videos, images, voice, avatars, translations, and edits with Agents in one place.项目地址: https://gitcode.com/GitHub_Trending/kr/OpenCreator创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表