feat: upgrade MiniMax default model to M3

[octo-patch]

Reason: Refresh the existing MiniMax integration with current model parameters and China-region TTS endpoint parity.

Changes

• Update MiniMax-M3 and MiniMax-M2.7 context, pricing, input modality, and thinking metadata.
• Keep the model catalog aligned with the current supported model set.
• Add credential-selectable global and China TTS endpoints.
• Preserve the resolved max-token value when resetting the chat wrapper.
• Add focused parameter and endpoint tests.

Checks

• pnpm install --frozen-lockfile
• ./.husky/pre-commit
• pnpm --filter flowise-components exec jest --runInBand src/minimaxParameters.test.ts
• pnpm --filter flowise-components build
• git diff --check
• git diff --cached --check

[gemini-code-assist]

Code Review

This pull request introduces support for MiniMax services, including a new ChatMiniMax model node, MiniMax API credentials, and MiniMax Text-to-Speech (TTS) integration. Feedback on the changes highlights a critical bug in the TTS stream processing where the loop does not fully terminate and the stream reader is not cancelled on error or abort, leading to potential resource leaks. Additionally, the falsy checks for temperature and topP in the ChatMiniMax node should be updated to safe nullish checks to allow valid values of 0.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

There are two critical issues in processMinimaxStream:

1. The break statement on line 200 only exits the inner for (const line of lines) loop. The outer for (;;) loop continues to run and call reader.read(), causing unnecessary processing and potential hangs.
2. If an error occurs (status_code !== 0) or the stream is aborted, the stream reader is not properly cancelled, leading to resource/connection leaks.

Using a labeled loop (outerLoop) and ensuring reader.cancel() is called on all exit paths resolves these issues. Additionally, throwing an error when the API returns an invalid status code promotes fail-fast behavior.

const processMinimaxStream = async () => {
    try {
        outerLoop: for (;;) {
            if (abortController.signal.aborted) {
                await reader.cancel();
                streamDestroyed = true;
                reject(new Error("TTS generation aborted"));
                return;
            }

            const { done, value } = await reader.read();
            if (done) break;

            sseBuffer += decoder.decode(value, { stream: true });
            const lines = sseBuffer.split("\n");
            sseBuffer = lines.pop() || "";

            for (const line of lines) {
                const trimmedLine = line.trim();
                if (!trimmedLine || trimmedLine.startsWith(":")) {
                    continue;
                }

                if (trimmedLine.startsWith("data:")) {
                    const jsonStr = trimmedLine.slice(5).trim();
                    if (!jsonStr) continue;

                    try {
                        const eventData = JSON.parse(jsonStr);

                        if (eventData.base_resp?.status_code !== 0) {
                            const errorMsg = eventData.base_resp?.status_msg || "Unknown error";
                            await reader.cancel();
                            reject(new Error("MiniMax TTS error: " + errorMsg));
                            return;
                        }

                        if (eventData.data?.audio) {
                            const audioChunk = Buffer.from(eventData.data.audio, "hex");
                            onChunk(audioChunk);
                        }

                        if (eventData.data?.status === 2) {
                            await reader.cancel();
                            break outerLoop;
                        }
                    } catch {
                        // Skip malformed JSON
                    }
                }
            }
        }

        onEnd();
        resolve();
    } catch (err) {
        await reader.cancel().catch(() => {});
        reject(err);
    }
}

References

1. When handling potentially invalid data from external sources (like an API response), prefer throwing an error for invalid input types rather than silently returning a default or empty value. This promotes fail-fast behavior.

[gemini-code-assist]

Checking if (temperature) can fail when temperature is resolved as the number 0 (which is falsy in JavaScript), preventing users from setting a deterministic temperature of 0. It is safer to check temperature != null && temperature !== '' to allow 0 as a valid value. Similarly, topP should be checked safely. Use loose equality (!= null) as a standard idiom for nullish checks.

Suggested change

	if (temperature) obj.temperature = parseFloat(temperature)
	if (maxTokens) obj.maxTokens = parseInt(maxTokens, 10)
	if (topP) obj.topP = parseFloat(topP)
	if (cache) obj.cache = cache
	if (temperature != null && temperature !== '') obj.temperature = parseFloat(temperature)
	if (maxTokens) obj.maxTokens = parseInt(maxTokens, 10)
	if (topP != null && topP !== '') obj.topP = parseFloat(topP)
	if (cache) obj.cache = cache

References

1. In JavaScript/TypeScript, use loose equality (== null) as a standard idiom for a 'nullish' check that covers both null and undefined.