fix(generation): 按动作类型取帧数 - #567
Merged
johnnyzhang-eng merged 1 commit intoAug 24, 2026
Merged
Conversation
32 既是所有动作的默认帧数,又被前端当成"这是完整动画任务"的判据,于是改任何一个动作 的帧数都会让前端把这类任务判成认不出来。而待机是原地小幅呼吸,32 帧里绝大多数帧之间 没有差别,多出来的帧进不了有效循环,却照样占抽帧、抠图、对齐、上传的工作量与存储。 帧数约定只留在后端 ACTION_FRAME_COUNTS 一处(待机 12,其余动作不变),请求显式传值时 以请求为准;前端提交时不再发 num_frames,改从任务的 input_payload 读回来当结果帧数 的判据。前端阶段改由 task_type 与 action_type 判定,不再依赖帧数取值。 Refs 1024XEngineer#478
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Contributor
There was a problem hiding this comment.
Review
审查了后端帧数约定与任务落库/MQ 重建链路、前端任务/SSE 映射、工作流审核节点以及对应测试和 OpenAPI 变更。ACTION_FRAME_COUNTS、显式 num_frames 覆盖、待机 12 帧、按任务声明校验结果帧数和移除前端固定 32 帧闸之间的契约保持一致,未发现满足报告阈值的正确性、兼容性或安全问题。
本地已通过 Python 编译检查和 git diff --check。未能在当前环境执行完整 pytest、Vitest、lint 或类型检查:环境未安装 uv/pytest,且前端依赖未安装;PR 描述中的 CI 验证结果未重复执行。
xyh202131
approved these changes
Aug 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #478
32既是所有动作的默认帧数,又被前端当成「这是完整动画任务」的判据,所以改任何一个动作的帧数都会让前端把这类任务判成认不出来。待机是原地小幅呼吸,32 帧里绝大多数帧之间没有差别,多出来的帧进不了有效循环,却照样占抽帧、抠图、对齐、上传的工作量与存储。帧数约定只留一处:后端
ACTION_FRAME_COUNTS(待机 12,其余动作不变),请求显式传值时以请求为准。前端提交时不再发num_frames,改从任务的input_payload读回来当结果帧数的判据——两边各写一个数的话,分叉时任务照跑、没有一处会红。解析放在
CharacterActionInput.__post_init__而不是各个构造点,让「漏一个构造点」在结构上不可能:全仓只有generation.py:425与handlers.py:82两处构造,两处都过这道。落库的input_payload是产线与前端读帧数的唯一来源。贯通链:
web/api/generation.py:197→:433→orchestrator/model.py:121-123(__post_init__→frames_for)→service.py:51(asdict 落库)→ MQ →worker/handlers.py:81,88(重建,缺就传 None 再过同一道解析)→:130→executor.py:344前端阶段判定改用
task_type与action_type,不再依赖帧数取值。另外features/workflow-controller/controller.ts有第二道写死 32 的闸(COMPLETE_ANIMATION_FRAME_COUNT),不一并改的话待机 12 帧会在审核节点被判「完整动画应为 32 帧,实际为 12 帧」,整个改动白做。验证
六个变异体全部转红(脚本 +
try/finally,四个文件 sha256 还原一致):inferExpectation退回num_frames === 32动作任务 input_payload.num_frames 无法映射到前端阶段num_frames: 32expected {...} to not have property "num_frames"mapActionResult退回expectedFrameCount = 32完整动画结果必须包含 32 帧__post_init__退回填 32assert 32 == 12(API 与入参两条)or 16assert 16 == 12(只有 MQ 那条红,证明测的确实是重建路径)完整动画应为 32 帧,实际为 0 帧本分支验证:后端
ruff check .通过、lint-imports2 kept 0 broken、export_openapi后openapi.json无漂移、pytest -q1335 passed / 14 skipped;前端format:check204 文件通过、oxlint与tsc -b无输出、vitest70 文件 998 用例全过、build成功。未覆盖
input_payload时前端跳过帧数比对(仍校验帧序从 0 连续),不换成另一个前端猜的数。生产每条事件都带,该分支走不到;若将来事件体瘦身,这道校验会静默失效。generate_rendered是否真按num_frames出帧未验,本次不改抽帧算法。entities/generation/api.ts,两边 hunk 不重叠(旧行 296 vs 302-316),可干净合并。