openclaw - 💡(How to fix) Fix [feature] MiniMax music_generation provider: use async-task polling instead of single blocking HTTP request

Summary

The MiniMax music_generation provider in extensions/minimax/music-generation-provider.ts uses a single blocking HTTP request to https://api.minimax.io/v1/music_generation. Any track that takes longer to render than the provider's DEFAULT_TIMEOUT_MS (120s) fails with a fetch timeout — even though the MiniMax API is still working server-side and would have returned audio.

This is normal MiniMax behavior for full-length tracks (240-300s of audio typically take 2-5 minutes wall-clock to render). It is impossible to reliably generate a full-length track through this provider with the current default timeout.

The bug is structural, not a timeout-tuning issue. Even with agents.defaults.musicGenerationModel.timeoutMs = 600000 as a workaround, a single long-lived HTTP connection across that span is fragile (proxies, dispatcher pools, connection resets).

Reproduction

1. Set agents.defaults.musicGenerationModel.primary = "minimax/music-2.6".
2. Set MINIMAX_API_KEY in env.
3. Call music_generate with a prompt targeting durationSeconds: 240-300.
4. The fetch fails around the 120-second mark with fetch-timeout: timeoutMs=120000, elapsedMs=120001.

Gateway log signature:

url: https://api.minimax.io/v1/music_generation
=> music-generation candidate failed: minimax/music-2.6

Proposed Fix

MiniMax's API supports async-task polling for music generation, identical in shape to their video API:

1. POST /v1/music_generation → returns task_id immediately
2. GET /v1/query/music_generation?task_id=<id> → poll until status: "Success" or "Fail"
3. Download the resulting audio_url

This pattern is already implemented in the same extension for video generation: see extensions/minimax/video-generation-provider.ts, the pollMinimaxVideo() function (~line 160). It uses the project's standard createProviderOperationDeadline(), waitProviderOperationPollInterval(), and MAX_POLL_ATTEMPTS helpers — all readily reusable for a pollMinimaxMusic() sibling.

Porting the same pattern to music-generation-provider.ts would:

• Eliminate the long single-connection HTTP wall (each polled request is short)
• Cleanly propagate the existing timeoutMs operation deadline up to the runtime's agents.defaults.musicGenerationModel.timeoutMs config
• Match the established pattern other long-running generation endpoints in the same provider already use

Workaround until fixed

// openclaw.json
{
  "agents": {
    "defaults": {
      "musicGenerationModel": {
        "primary": "minimax/music-2.6",
        "timeoutMs": 600000  // raise from default 120000
      }
    }
  }
}

This makes full-length renders succeed in normal cases but doesn't fix the structural fragility of a multi-minute blocking HTTP connection.

Impact

Anyone using MiniMax as their primary music-generation provider for tracks longer than ~2 minutes (i.e. anything beyond a short clip) hits this. NOVA's daily music composition pipeline was silently falling through to Google Lyria (3-min hard cap, abrupt ending) every day because of it.

Environment

• OpenClaw: nova-openclaw fork (current main as of 2026-05-20)
• MiniMax provider: extensions/minimax/music-generation-provider.ts
• Model: minimax/music-2.6