fix(minimax): stop advertising music duration control#84585
fix(minimax): stop advertising music duration control#84585neeravmakwana wants to merge 3 commits into
Conversation
|
Codex review: needs maintainer review before merge. Workflow note: Future ClawSweeper reviews update this same comment in place. How this review workflow works
Summary Reproducibility: yes. Current main source shows MiniMax advertises duration support, only prompt-embeds the requested duration, and sends no structured duration field; the linked issue also gives a concrete PR rating Rank-up moves:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. Real behavior proof Risk before merge
Maintainer options:
Next step before merge Security Review detailsBest possible solution: Merge this after maintainer acceptance of the compatibility tradeoff: MiniMax should not advertise duration support until the vendor publishes a structured duration request field. Do we have a high-confidence way to reproduce the issue? Yes. Current main source shows MiniMax advertises duration support, only prompt-embeds the requested duration, and sends no structured duration field; the linked issue also gives a concrete Is this the best way to solve the issue? Yes. The patch matches the official MiniMax request schema and reuses the existing shared unsupported-override path instead of inventing or relying on an undocumented vendor field. Label changes:
Label justifications:
What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against c8a953af9371. |
|
ClawSweeper PR egg ✨ Hatched: 🥚 common Moonlit Shellbean Hatch commandComment Hatchability rules:
Rarity: 🥚 common. What is this egg doing here?
|
|
Added stronger real behavior proof to the PR body. What I added:
The live MiniMax log still has the API key redacted. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
I have updated the MiniMax provider doc too. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper merge |
|
@clawsweeper automerge |
|
🦞🔧
Draft PRs stay fix-only until GitHub marks them ready for review. Pause with Automerge progress:
|
|
ClawSweeper 🐠 reef update Thanks for the work here. GitHub would not let ClawSweeper push to this branch with the available credentials, so the fix moved to a narrow replacement PR. nothing personal, just permission currents. Why replacement: ClawSweeper could not update the source PR branch directly; GitHub did not grant sufficient push rights to the bot for that branch.
fish notes: model gpt-5.5, reasoning high; reviewed against 1c616da. |
Summary
durationSecondssupport because the official MiniMax/v1/music_generationrequest contract does not document a duration field.Fixes #84508
Root Cause
The MiniMax music provider claimed
supportsDuration: true, butdurationSecondswas only converted into prompt text. That made the sharedmusic_generatecapability advertise a runtime control that MiniMax does not actually enforce through a documented structured API field.Why This Is Safe
This narrows the advertised MiniMax capability to match the vendor API contract and existing runtime behavior. Callers that request duration through the shared music generation runtime now get the normal unsupported-override handling instead of a misleading MiniMax-specific prompt hint.
Security/runtime controls are unchanged: provider authentication, HTTP request configuration, private-network blocking, response validation, download handling, and mp3-only format validation are untouched.
Real behavior proof
Behavior addressed: MiniMax music generation no longer advertises durationSeconds support because the official MiniMax
/v1/music_generationAPI contract does not document a duration request field.Real environment tested: Local macOS checkout with
MINIMAX_API_KEYconfigured from.env, using the patched provider code. Secret values were not printed; the live provider log is redacted.Exact steps or command run after this patch:
Capability and ignored-override evidence after fix:
{ "provider": "minimax", "model": "music-2.6", "advertisedControls": { "supportsLyrics": true, "supportsInstrumental": true, "supportsDuration": false, "supportsFormat": true, "supportedFormats": [ "mp3" ] }, "requestedOverrides": { "durationSeconds": 30, "format": "mp3" }, "sanitizedRequest": { "durationSeconds": null, "format": "mp3" }, "ignoredOverrides": [ { "key": "durationSeconds", "value": 30 } ] }Live MiniMax generation evidence after fix:
Observed result after fix: MiniMax no longer advertises duration support, the shared runtime normalization drops
durationSecondsand records it as an ignored override, and MiniMax still generates an audio track successfully through the live provider path.What was not tested: I did not verify MiniMax duration control because the official MiniMax API reference does not expose a documented duration request parameter.
Verification
pnpm docs:listgit diff --checkpnpm test extensions/minimax/music-generation-provider.test.tspnpm check:changednode --import tsx --input-type=module ...capability/ignored-override proof shown aboveOPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_TEST_QUIET=0 OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS=minimax pnpm test:live -- extensions/music-generation-providers.live.test.ts --reporter=verboseOut of Scope