chenhg5/cc-connect · error

minimax tts: read SSE stream: %w

Error message

minimax tts: read SSE stream: %w

What it means

This wraps the terminal error from bufio.Scanner while reading the MiniMax SSE stream (scanner.Err()). It means the response body could not be fully read — the connection broke or an I/O error occurred mid-stream, before the status=2 trailer chunk arrived. Any audio decoded so far is discarded.

Source

Thrown at core/tts.go:402

			return nil, "", fmt.Errorf("minimax tts API error %d: %s", chunk.BaseResp.StatusCode, chunk.BaseResp.StatusMsg)
		}
		// MiniMax T2A v2 stream protocol: status=1 carries incremental audio
		// chunks; the final status=2 chunk re-sends the full audio as a
		// trailer for non-stream clients. Appending the trailer doubles the
		// audio length and makes the spoken text play twice, so skip it.
		if chunk.Data.Status == 2 {
			break
		}
		if chunk.Data.Audio != "" {
			audioBytes, err := hex.DecodeString(chunk.Data.Audio)
			if err != nil {
				return nil, "", fmt.Errorf("minimax tts: decode audio hex: %w", err)
			}
			audioBuf.Write(audioBytes)
		}
	}
	if err := scanner.Err(); err != nil {
		return nil, "", fmt.Errorf("minimax tts: read SSE stream: %w", err)
	}
	if audioBuf.Len() == 0 {
		return nil, "", fmt.Errorf("minimax tts: no audio data received")
	}
	return audioBuf.Bytes(), "mp3", nil
}

// ──────────────────────────────────────────────────────────────
// MimoTTS — Xiaomi MiMo-V2.5-TTS implementation
// ──────────────────────────────────────────────────────────────

// MimoTTS implements TextToSpeech using the Xiaomi MiMo-V2.5-TTS API,
// which is shaped like OpenAI chat completions: the synthesis text rides
// on an assistant message and audio bytes come back base64-encoded inside
// choices[0].message.audio.data.
//
// Docs: https://platform.xiaomimimo.com/#/docs/usage-guide/speech-synthesis
type MimoTTS struct {

View on GitHub (pinned to 4000b2338a)

Solutions

1. Retry the Synthesize call — mid-stream disconnects are usually transient.
2. Increase the HTTP client's timeout so long TTS streams are not cut off.
3. Check for a gateway/proxy with a low idle/read timeout and raise it or stream directly.
4. If persistent, capture the wrapped error to see if it is connection reset, unexpected EOF, or context deadline and address that root cause.

for attempt := 0; attempt < 3; attempt++ {
    audio, format, err := tts.Synthesize(ctx, text, voice)
    if err == nil { break }
    if strings.Contains(err.Error(), "read SSE stream") {
        time.Sleep(backoff(attempt)); continue
    }
    return err
}

When it happens

Trigger: Connection reset or timeout while streaming chunks; server closed the connection prematurely; resp.Body read fails due to network interruption; scanner buffer still exceeded (though it is set to 10MB, very large lines could still error).

Common situations: Flaky Wi-Fi/mobile network during long TTS generation; LB/gateway idle-timeout killing slow streams; VPN drop mid-request.

Related errors

• minimax tts: request: %w
• minimax tts: decode audio hex: %w
• minimax tts: no audio data received
• openai tts: request: %w
• openai tts: read audio: %w

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/edb38a8f28dd8a45. Report an issue: GitHub.