Skip to content

fix(generation): 按动作类型取帧数 - #567

Merged
johnnyzhang-eng merged 1 commit into
1024XEngineer:mainfrom
johnnyzhang-eng:fix/frames-per-action-type
Aug 24, 2026
Merged

fix(generation): 按动作类型取帧数#567
johnnyzhang-eng merged 1 commit into
1024XEngineer:mainfrom
johnnyzhang-eng:fix/frames-per-action-type

Conversation

@johnnyzhang-eng

Copy link
Copy Markdown
Contributor

Closes #478

32 既是所有动作的默认帧数,又被前端当成「这是完整动画任务」的判据,所以改任何一个动作的帧数都会让前端把这类任务判成认不出来。待机是原地小幅呼吸,32 帧里绝大多数帧之间没有差别,多出来的帧进不了有效循环,却照样占抽帧、抠图、对齐、上传的工作量与存储。

帧数约定只留一处:后端 ACTION_FRAME_COUNTS(待机 12,其余动作不变),请求显式传值时以请求为准。前端提交时不再发 num_frames,改从任务的 input_payload 读回来当结果帧数的判据——两边各写一个数的话,分叉时任务照跑、没有一处会红。

解析放在 CharacterActionInput.__post_init__ 而不是各个构造点,让「漏一个构造点」在结构上不可能:全仓只有 generation.py:425handlers.py:82 两处构造,两处都过这道。落库的 input_payload 是产线与前端读帧数的唯一来源。

贯通链:web/api/generation.py:197:433orchestrator/model.py:121-123__post_init__frames_for)→ service.py:51(asdict 落库)→ MQ → worker/handlers.py:81,88(重建,缺就传 None 再过同一道解析)→ :130executor.py:344

前端阶段判定改用 task_typeaction_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: 32 expected {...} to not have property "num_frames"
mapActionResult 退回 expectedFrameCount = 32 完整动画结果必须包含 32 帧
后端 __post_init__ 退回填 32 assert 32 == 12(API 与入参两条)
MQ 重建退回 or 16 assert 16 == 12(只有 MQ 那条红,证明测的确实是重建路径)
controller 退回 32 帧闸 完整动画应为 32 帧,实际为 0 帧

本分支验证:后端 ruff check . 通过、lint-imports 2 kept 0 broken、export_openapiopenapi.json 无漂移、pytest -q 1335 passed / 14 skipped;前端 format:check 204 文件通过、oxlinttsc -b 无输出、vitest 70 文件 998 用例全过、build 成功。

未覆盖

  • 待机 12 帧的观感没有实测证据,本次只落实机制,帧数取值是产品口径。
  • SSE 事件缺 input_payload 时前端跳过帧数比对(仍校验帧序从 0 连续),不换成另一个前端猜的数。生产每条事件都带,该分支走不到;若将来事件体瘦身,这道校验会静默失效。
  • 三渲二 generate_rendered 是否真按 num_frames 出帧未验,本次不改抽帧算法。
  • fix(export): 脚线几何由后端报出,前端不再自己按 0.92 算 #524 同改 entities/generation/api.ts,两边 hunk 不重叠(旧行 296 vs 302-316),可干净合并。

32 既是所有动作的默认帧数,又被前端当成"这是完整动画任务"的判据,于是改任何一个动作
的帧数都会让前端把这类任务判成认不出来。而待机是原地小幅呼吸,32 帧里绝大多数帧之间
没有差别,多出来的帧进不了有效循环,却照样占抽帧、抠图、对齐、上传的工作量与存储。

帧数约定只留在后端 ACTION_FRAME_COUNTS 一处(待机 12,其余动作不变),请求显式传值时
以请求为准;前端提交时不再发 num_frames,改从任务的 input_payload 读回来当结果帧数
的判据。前端阶段改由 task_type 与 action_type 判定,不再依赖帧数取值。

Refs 1024XEngineer#478
@vercel

vercel Bot commented Aug 23, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
windup Ready Ready Preview Aug 23, 2026 5:27pm

@codecov

codecov Bot commented Aug 23, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 89.47368% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
frontend/src/entities/generation/api.ts 77.77% 1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review

审查了后端帧数约定与任务落库/MQ 重建链路、前端任务/SSE 映射、工作流审核节点以及对应测试和 OpenAPI 变更。ACTION_FRAME_COUNTS、显式 num_frames 覆盖、待机 12 帧、按任务声明校验结果帧数和移除前端固定 32 帧闸之间的契约保持一致,未发现满足报告阈值的正确性、兼容性或安全问题。

本地已通过 Python 编译检查和 git diff --check。未能在当前环境执行完整 pytest、Vitest、lint 或类型检查:环境未安装 uv/pytest,且前端依赖未安装;PR 描述中的 CI 验证结果未重复执行。

@johnnyzhang-eng
johnnyzhang-eng merged commit 896821d into 1024XEngineer:main Aug 24, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(generation): 待机按 32 帧生成,帧数被当成前端阶段判据

2 participants