feat(ali): 适配阿里万相 wan2.7 并修复密钥聚合模式下异步任务轮询失败问题 - #4272
Closed
wans10 wants to merge 10 commits into
Closed
Conversation
- Added `wan2.7-i2v` to the model list - Implemented `AliMediaItem` and updated `AliVideoInput` to support the new media array protocol - Updated request conversion logic to handle model-specific input parameters and resolutions - Expanded `AliUsage` to include input and output video duration statistics
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdd wan2.7+ model handling to the Alibaba adaptor (media-array video input, model-detection helper, resolution change), extend usage metrics, add Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
relay/channel/task/ali/adaptor.go (1)
191-194: Align helper naming/comment with actual predicate scope.Line 191 says “wan2.7+”, but Line 193 only matches
wan2.7*. Consider either broadening logic or renaming/commenting it as “wan2.7-series” to avoid future misrouting assumptions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@relay/channel/task/ali/adaptor.go` around lines 191 - 194, The comment claims “wan2.7+” but the predicate isWan27Model only checks strings.HasPrefix(model, "wan2.7"), so update the naming/comment to reflect the actual scope: rename isWan27Model to isWan27SeriesModel and change the comment to indicate "wan2.7 系列模型（使用新版 media 数组协议）", or alternatively broaden the predicate if you truly mean "2.7 and newer"; locate the function isWan27Model and the strings.HasPrefix(model, "wan2.7") usage and make the corresponding rename and comment change (plus update all call sites) so the code and documentation match.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@relay/channel/task/ali/adaptor.go`:
- Around line 323-325: The branching that sets aliReq.Parameters.Resolution to
"1080P" currently checks req.Model but the function already computes a mapped
model in upstreamModel (see lines where upstreamModel is derived); update the
condition to use upstreamModel (or call isWan27Model(upstreamModel)) instead of
req.Model so mapped wan2.7 models correctly get the 1080P default; ensure all
subsequent model-prefix checks (e.g., strings.HasPrefix) also use upstreamModel
for consistency.
---
Nitpick comments:
In `@relay/channel/task/ali/adaptor.go`:
- Around line 191-194: The comment claims “wan2.7+” but the predicate
isWan27Model only checks strings.HasPrefix(model, "wan2.7"), so update the
naming/comment to reflect the actual scope: rename isWan27Model to
isWan27SeriesModel and change the comment to indicate "wan2.7 系列模型（使用新版 media
数组协议）", or alternatively broaden the predicate if you truly mean "2.7 and
newer"; locate the function isWan27Model and the strings.HasPrefix(model,
"wan2.7") usage and make the corresponding rename and comment change (plus
update all call sites) so the code and documentation match.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b6943406-4abf-4317-a4a1-134f224f46cf
📒 Files selected for processing (2)
relay/channel/task/ali/adaptor.gorelay/channel/task/ali/constants.go
…ng and logic checks
wans10
changed the title
- 优化 Base64 解码逻辑：引入 UTF-8 感知的解码方法（使用 TextDecoder/Uint8Array），替换原有的简单 `atob`，修复包含非拉丁字符时解码失败的问题。 - 增强阶梯标签匹配机制：新增标签规范化处理（移除空格、统一大小写、转换 `<`/`≤`/`<=` 等符号），确保日志记录中的标签能够与配置中的标签准确匹配。 - 将上述修复同步应用于 default 和 classic 两套前端主题。
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
web/default/src/features/usage-logs/lib/format.ts (1)
160-178: Cross-environment base64 decoding is well-handled, butanytype usage should be avoided.The decoding logic correctly handles browser vs Node environments. However, line 176 uses
anytype which violates the coding guideline.♻️ Proposed fix: use explicit type annotation
return decodeURIComponent( Array.prototype.map - .call(bytes, (byte: any) => '%' + byte.toString(16).padStart(2, '0')) + .call(bytes, (byte: number) => '%' + byte.toString(16).padStart(2, '0')) .join('') )As per coding guidelines: "Avoid
anytype in TypeScript; prefer specific types orunknown"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/default/src/features/usage-logs/lib/format.ts` around lines 160 - 178, Replace the use of the any type in the Array.prototype.map callback by typing the mapped parameter as a number (e.g., change the callback signature from (byte: any) => ... to (byte: number) => ...), since the source Uint8Array (bytes) yields numbers; update the map callback reference accordingly so TypeScript recognizes the parameter type and remove the any usage in that mapping expression that builds the percent-encoded string.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@web/classic/src/helpers/render.jsx`:
- Around line 2295-2302: normalizeLabel incorrectly normalizes "<=" and ">="
because the regex alternatives match the single-char "<" or ">" first; update
the two replace regexes in normalizeLabel to match the longer sequences first
(e.g., use alternatives that list "<=" before "<" and ">=" before ">") so "<="
and ">=" are replaced to "<" and ">" correctly, keeping the existing
replacements for the unicode characters (≤, ≥), the whitespace removal, and
toLowerCase behavior.
In `@web/default/src/features/usage-logs/lib/format.ts`:
- Around line 184-191: In normalizeTierLabel, the regex alternation orders
shorter tokens before longer ones so "<" matches before "<=" and prevents
normalizing "<=" to "<"; update the patterns used in normalizeTierLabel (the two
.replace calls that target <=/≤/< and >=/≥/> ) to list longer sequences first
(e.g., match "<=" before "<" and ">=" before ">") so the multi-character
operators normalize correctly while keeping the subsequent .replace(/\s/g, '')
and .toLowerCase() calls intact.
---
Nitpick comments:
In `@web/default/src/features/usage-logs/lib/format.ts`:
- Around line 160-178: Replace the use of the any type in the
Array.prototype.map callback by typing the mapped parameter as a number (e.g.,
change the callback signature from (byte: any) => ... to (byte: number) => ...),
since the source Uint8Array (bytes) yields numbers; update the map callback
reference accordingly so TypeScript recognizes the parameter type and remove the
any usage in that mapping expression that builds the percent-encoded string.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a63ff397-0091-4b24-bd9e-6acd6c05cf4f
📒 Files selected for processing (2)
web/classic/src/helpers/render.jsxweb/default/src/features/usage-logs/lib/format.ts
Comment on lines
+2295
to
+2302
| export const normalizeLabel = (label) => { | ||
| if (!label) return ''; | ||
| return label | ||
| .replace(/<|≤|<=/g, '<') | ||
| .replace(/>|≥|>=/g, '>') | ||
| .replace(/\s/g, '') | ||
| .toLowerCase(); | ||
| }; |
Contributor
There was a problem hiding this comment.
Regex alternation order prevents proper normalization of <= and >=.
The regex /<|≤|<=/g tries alternatives left-to-right at each position. When encountering <=, the engine matches < first (at position 0) and moves on, leaving = unprocessed. This means:
≤→<✓<=→<=(unchanged) ✗
Similarly for />|≥|>=/g. If a tier label uses <= and matched_tier uses ≤ (or vice versa), they won't match after normalization.
🐛 Proposed fix: reorder alternatives to match longer sequences first
export const normalizeLabel = (label) => {
if (!label) return '';
return label
- .replace(/<|≤|<=/g, '<')
- .replace(/>|≥|>=/g, '>')
+ .replace(/<=|≤|</g, '<')
+ .replace(/>=|≥|>/g, '>')
.replace(/\s/g, '')
.toLowerCase();
};🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/classic/src/helpers/render.jsx` around lines 2295 - 2302, normalizeLabel
incorrectly normalizes "<=" and ">=" because the regex alternatives match the
single-char "<" or ">" first; update the two replace regexes in normalizeLabel
to match the longer sequences first (e.g., use alternatives that list "<="
before "<" and ">=" before ">") so "<=" and ">=" are replaced to "<" and ">"
correctly, keeping the existing replacements for the unicode characters (≤, ≥),
the whitespace removal, and toLowerCase behavior.
Comment on lines
+184
to
+191
| export function normalizeTierLabel(label: string | undefined): string { | ||
| if (!label) return '' | ||
| return label | ||
| .replace(/<|≤|<=/g, '<') | ||
| .replace(/>|≥|>=/g, '>') | ||
| .replace(/\s/g, '') | ||
| .toLowerCase() | ||
| } |
Contributor
There was a problem hiding this comment.
Same regex alternation ordering issue as in render.jsx.
The regex /<|≤|<=/g will not properly normalize <= to < because < matches first. This causes tier matching failures when one side uses <= and the other uses ≤.
🐛 Proposed fix: reorder alternatives to match longer sequences first
export function normalizeTierLabel(label: string | undefined): string {
if (!label) return ''
return label
- .replace(/<|≤|<=/g, '<')
- .replace(/>|≥|>=/g, '>')
+ .replace(/<=|≤|</g, '<')
+ .replace(/>=|≥|>/g, '>')
.replace(/\s/g, '')
.toLowerCase()
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@web/default/src/features/usage-logs/lib/format.ts` around lines 184 - 191, In
normalizeTierLabel, the regex alternation orders shorter tokens before longer
ones so "<" matches before "<=" and prevents normalizing "<=" to "<"; update the
patterns used in normalizeTierLabel (the two .replace calls that target <=/≤/<
and >=/≥/> ) to list longer sequences first (e.g., match "<=" before "<" and
">=" before ">") so the multi-character operators normalize correctly while
keeping the subsequent .replace(/\s/g, '') and .toLowerCase() calls intact.
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
1 participant
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.
Important
📝 变更描述 / Description
本次变更主要实现了对阿里万相 wan2.7 系列模型的支持，并适配了其最新的媒体输入协议，同时修复了密钥聚合模式下异步视频任务无法推进的问题。
img_url字符串字段，转而采用media数组协议（[{"type": "image", "url": "..."}]）。代码中新增了AliMediaItem结构，并根据模型前缀自动切换协议，确保了与旧版模型（wan2.6 及以下）的向下兼容。ModelList中正式加入wan2.7-i2v模型。1080P。AliUsage结构，新增了输入和输出视频时长的统计字段，为后续更精细的业务审计和计费提供了数据支持。InitTask中，当渠道启用密钥聚合模式（ChannelIsMultiKey）时，将请求实际使用的密钥存储至task.PrivateData.Key，轮询时优先使用该值。此修复同样适用于其他类型的异步任务渠道（如 Kling、Ali 等）。🚀 变更类型 / Type of change
🔗 关联任务 / Related Issue
✅ 提交前检查项 / Checklist
Bug fix，我已提交或关联对应 Issue，且不会将设计取舍、预期不一致或理解偏差直接归类为 bug。📸 运行证明 / Proof of Work
wan2.7 协议适配：
修复了调用 wan2.7-i2v 时报
Field required: input.media的协议兼容性问题。经测试，发送包含
input_reference的请求时，系统能正确根据模型版本：wan2.7：将其包装为media数组发送至上游。wan2.6及以下：继续使用img_url字段发送。生成的视频任务已能成功在阿里后台创建并正常处理。
密钥聚合模式 Bug 修复：
修复了字节火山方舟/豆包通用渠道在密钥聚合模式下，视频任务提交成功但任务日志中任务状态始终显示"未启动"的问题。
经测试，启用密钥聚合（随机/轮询）的渠道下，视频生成任务现可正常推进并最终完成。
Summary by CodeRabbit
New Features
Bug Fixes