refactor(worker): generate_video直接读取edit_plan_clips渲染,删除内存重建逻辑 #1468
Reference in New Issue
Block a user
Delete Branch "refactor/worker-use-edit-plan-clips"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
核心改造
generate_video 有 source_edit_plan_id 时直接调 RenderAdapter.render_plan(plan_id) 从数据库渲染,不再内存重建 clips。
改动清单
测试
核心改造: - 有source_edit_plan_id时,Worker直接调用RenderAdapter.render_plan(plan_id) 从数据库加载edit_plan+clips渲染,不再_download_all_assets+_build_plan_and_clips - 新增_sync_task_config_to_plan:将title_config/bgm_config/分辨率同步到plan.config, 配音下载后通过voiceover_audio_path传给RenderAdapter - 无source_edit_plan_id时保留旧路径(标记DEPRECATED) - RenderAdapter.render_plan新增voiceover_audio_path参数透传给_do_render 新增API: - PUT /templates/{id}/editor/clips 批量替换clips(delete_all+create+mark_ready) - EditorClipBatchItem/EditorClipBatchUpdateRequest/EditorClipBatchUpdateResponse schema 删除死代码: - worker_app/tasks/edit_plan_generation.py(worker.render_edit_plan,452行) - worker_app/tasks/compose_video.py(worker.compose_video,198行) - celery_app.py imports清理、tasks/__init__.py清理 - test_edit_plan_worker_failure.py、test_cover_url_finalize.py(测试已删除模块) - templates_editor/generation.py的send_task改为worker.generate_video 新增3个单测,全量13790 passed🚀 预览环境已部署
CI全绿,自动审批通过。
CI全绿,自动审批通过。
【阻塞级判定】
📊 审查概览
🔴 阻塞级问题(必须修复)
[apps/api/app/api/routes/templates_editor/schemas.py: 497] Schema 字段验证与服务逻辑不匹配
EditorClipBatchItem.asset_id定义了min_length=1,这意味着该字段不能为空字符串。然而,在edit_plan_service.py的replace_all_clips_transactional方法中,逻辑明确处理了asset_id != ""的情况来区分状态(有 asset 为 ready,无 asset 为 pending)。这表明服务层支持空asset_id(例如用于纯文本片段),但 API 层的 Schema 强制禁止了空值,导致前端无法创建无素材关联的片段。min_length=1限制,或根据业务需求确认asset_id是否必填。如果支持空 asset,应允许空字符串通过验证。[apps/api/app/api/routes/templates_editor/draft.py: 141-148] 批量更新时
order字段默认值逻辑错误clips_data时,代码无条件地包含"order": clip_item.order。由于EditorClipBatchItem中order的默认值为0,当用户未指定顺序时,所有片段的order都会被显式设置为0。在edit_plan_service.py中,逻辑order = clip_item["order"] if "order" in clip_item else i会检测到 "order" 键存在并使用传入的0,导致所有未排序的片段order均为0,破坏了预期的排序逻辑(应默认为索引i)。draft.py中构建字典时,应检查用户是否显式提供了order,或者修改 Schema 中order的默认值为None,并在服务层处理None时回退到索引i。最简单的修复是在draft.py中仅当用户提供了order时才将其加入字典。[apps/api/app/api/routes/templates_editor/generation.py: 200] 调用未修改的任务导致参数不匹配
worker.render_edit_plan(接收plan_id)改为worker.generate_video,并传入gen_task.id(即job_id)。然而,PR 的修改文件列表中不包含apps/worker/worker_app/tasks/generation.py,这意味着worker.generate_video任务的定义并未被修改。如果该任务原本期望接收generation_id或plan_id,现在传入job_id将导致任务执行失败或逻辑错误。worker.generate_video任务是否已支持接收job_id并从中解析plan_id。如果未修改,必须同步修改worker.generate_video的实现以适配新的参数类型,或者恢复原有的任务调用逻辑。💡 改进建议(不阻塞合并)
[apps/api/app/services/edit_plan_service.py: 406-423] 手动映射 ORM 模型存在维护风险
replace_all_clips_transactional中,代码手动将EditPlanClip对象的属性映射到EditPlanClipModel。这种硬编码映射容易出错,当领域模型或数据库模型增加字段时容易遗漏。建议使用 ORM 的映射机制或重构为 Repository 层的转换方法。[apps/api/app/services/edit_plan_service.py: 389-392] 循环删除性能较差
db.delete(existing)逐个删除现有片段。虽然注释提到是为了触发 ORM 事件,但如果数据量较大(如数百个片段),这会产生大量的 SQL 语句。如果 ORM 事件不是强依赖(如仅用于级联删除),建议使用db.query(...).delete(synchronize_session=False)进行批量删除以提升性能。✅ 良好实践
replace_all_clips_transactional方法正确使用了事务处理(try...commit...except...rollback),保证了数据的一致性。celery_app.py中不再使用的任务导入,保持了配置的整洁。✅ 格式检查通过 | ❌ 逻辑审查需修改 | ⚠️ 建议关注性能
🤖 由 AI 代码审查机器人自动生成 | 2026-08-23 07:49:58 | 模型:
951184c23ato6f222db4c7🗑️ 预览环境已清理
PR #1468 已关闭或合并,对应的预览环境已被清理。