fix: #1286 can_generate 增加最后防线自动修复,解决「没有可渲染的就绪片段」报错 #1288
Reference in New Issue
Block a user
Delete Branch "feature/1286-can-generate-auto-repair"
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?
问题
智能剪辑流程走完素材选择后,
can_generate(edit_plan_service.py:571)在mark_clips_ready之前执行。PR #1276 修的是mark_clips_ready,但报错来自can_generate,没覆盖到。根因:
generate_editor_draft的 fallback 链路(_fallback.py)太长太脆弱,任何一环出问题都导致最终can_generate验证失败,且无日志追踪。修复
1. can_generate 增加最后防线自动修复
如果 clips 存在但都没有 asset_id,且
config.asset_ids非空,直接在 can_generate 内部执行素材分配:2. _auto_fallback_assign_assets 增强
3. generation.py 防御性日志
测试
10 个新单元测试覆盖:
56 个已有 edit_plan_service 测试全部通过。
🚀 预览环境已部署
【阻塞级判定】
📊 审查概览
🔴 阻塞级问题(必须修复)
无
💡 改进建议(不阻塞合并)
[apps/api/app/services/edit_plan_service.py: 571] 方法副作用问题
can_generate方法通常作为“检查”类方法,应当是幂等的且无副作用的。当前实现中,该方法在特定条件下直接调用了self.assign_asset修改了数据库状态。虽然这是为了实现“最后一道防线”的自动修复业务逻辑,但这种“检查即修改”的行为违反了单一职责原则,可能导致调用者(如外部系统或测试用例)在未预料到数据变更的情况下产生副作用。建议如果可能,将自动修复逻辑提取到独立的方法(如auto_repair_assets),并在调用can_generate前显式调用,或者在can_generate内部调用但明确文档化此副作用风险。[apps/api/app/services/edit_plan_service.py: 603] 代码重复
edit_plan_service.py中的自动修复逻辑(遍历 clips 并分配 asset)与_fallback.py中的逻辑高度相似。虽然两者的触发时机和上下文不同(一个是服务层最后防线,一个是路由层兜底),但核心算法一致。建议考虑将通用的分配逻辑抽取为EditPlanService的一个私有方法(如_batch_assign_assets_clips),以减少代码重复,便于后续维护逻辑一致性。✅ 良好实践
_fallback.py和edit_plan_service.py的循环中均对assign_asset进行了try-except捕获,防止单个片段分配失败导致整个流程中断,并记录了详细的日志,便于排查问题。list_clips/list_by_plan)来验证修复结果,确保内存中的数据状态与数据库一致,避免了脏读或缓存问题。i % len(config_asset_ids)前均检查了config_asset_ids是否为空,有效避免了除零错误。✅ 格式检查通过 | ✅ 逻辑审查通过 | ✅ 性能良好
🤖 由 AI 代码审查机器人自动生成 | 2026-08-07 14:35:09 | 模型:
🗑️ 预览环境已清理
PR #1288 已关闭或合并,对应的预览环境已被清理。