[Frontend] Add Streaming Parser Engine and new MinimaxM2 Parser

[chaunceyjiang]

Purpose

[Frontend] Add Streaming Parser Engine and new MinimaxM2 Parser

Test Plan

Test Result

OPENAI_BASE_URL=http://localhost:8001/v1  OPENAI_API_KEY=dummy uv run python -m bfcl_eval generate \
    --model MiniMaxAI/MiniMax-M2.5-FC \
    --test-category multi_turn_base \
    --result-dir $PWD --num-threads 16

this pr

Rank,Model,Multi Turn Overall Acc,Base,Miss Func,Miss Param,Long Context
1,MiniMax-M2.5 (FC ChatCompletions),20.75%,83.00%,N/A,N/A,N/A

main

Rank,Model,Multi Turn Overall Acc,Base,Miss Func,Miss Param,Long Context
1,MiniMax-M2.5 (FC ChatCompletions),20.62%,82.50%,N/A,N/A,N/A

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @chaunceyjiang.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[sfeng33]

It might be worth thinking whether changes from PR #37790 can be adopted - adds validation to reject hallucinated function names that aren't in request.tools. The engine's _build_extracted_result does not filter tool calls by name. It extracts whatever the model produces, relying on _fix_arg_types for schema lookup but not for name validation.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @chaunceyjiang.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[bbrowning]

The longest-match buffering and draining in incremental_lexer.py for tokens that are entirely prefix of other tokens looks good - that's something I didn't anticipate needing to handle here, so I'm glad you were able to find a reasonable solution to that. And, it looks well guarded to not cause negative performance impacts on the happy path for models that don't use overlapping terminals.

The additional _check_skip_tool_parsing paths look like they fixed oversights I missed in the initial implementation here, so thanks for adding those in.

The new validate_tool_names config option looks wired in properly, and is a good flag to let models opt in/out of dropping of hallucinated function names vs returning back to clients.

I confirmed the changes to trace_builder.py get this properly wired in to the engine replay test suites, giving us broad coverage for the various buffering / holdback scenarios for this parser and all of those pass.

I have not run this model live with these changes. However, your BFCL results show this didn't regress in the non-stream parsing cases (what BFCL tests). That, combined with all the replay test suites verifying streaming behavior at various chunk sizes gives me confidence this is in good shape.

[bbrowning]

A nit: I think if we just update the reasoning to check for None instead of "" in SHORTEST_REASONING_NO_STREAMING (and EMPTY) this and the EMPTY test below will pass. I tested this locally and they passed, so I don't think we regressed here in any way if we want to keep this extra coverage.

[sfeng33]

Analysis

This PR migrates minimax_m2_tool_parser / MiniMaxM2ReasoningParser to the config-driven parser engine. Below is a breakdown of which existing issues and PRs are addressed (and which are not).

TL;DR

Category	Outcome	Superseded
1. Tool call args not streamed incrementally	✅ Fixed (parameter granularity)	#40253, #40298, #40975, #44107
2. Reasoning parser bugs	✅ Fixed (both)	#38213, #44898
3. Reasoning token accounting	⚠️ Partial	— (#37955 still needed)
4. Missing adjust_request	✅ Fixed	#42307
5. Function name validation	✅ Fixed (new)	#37790

---

Category 1: Tool Call Arguments Not Streamed Incrementally

All of these report the same root cause: the old parser buffers tool call arguments until a complete </invoke> block is received, causing multi-second delays.

Ref	Type	Title
#39649	Issue	minimax_m2_tool_parser does not stream tool call args
#40779	Issue	Function call content not streamed incrementally
#36073	Issue	Prolonged latency in streaming function call mode
#36116	Issue	Pseudo-streaming with tool parser (MiniMax-M2 + Qwen3)
#40253	PR	Stream MiniMax M2 tool-call deltas incrementally
#40298	PR	Implement incremental streaming for minimax_m2_tool_parser
#40975	PR	Fix MiniMax tool-call arguments not streamed incrementally
#44107	PR	Emit tool name blocks in advance in MinimaxM2

Does PR #45701 fix these? YES — at parameter granularity.

The updated PR sets stream_arg_deltas=True. The engine's _compute_arg_delta() is now called on every ARG_VALUE_CHUNK event, invoking the _minimax_m2_arg_converter with partial=True. Each time a complete <parameter>...</parameter> tag closes, the converter produces updated JSON, and the engine diffs it against the previously streamed JSON, emitting the delta.

How it works in practice: For a tool call with 3 parameters, the old parser waited until all 3 parameters AND </invoke> arrived. The new parser emits a delta after each </parameter> closes — so the client sees arguments arrive incrementally as each parameter completes. For a single long parameter value, there's no sub-parameter streaming (a fundamental XML format limitation), but multi-parameter calls see meaningful improvement.

Additionally, the engine emits the tool name as soon as the <invoke name="..."> header is parsed (addressed by #44107), rather than waiting for the full invoke block.

All four competing PRs (#40253, #40298, #40975, #44107) are superseded — they modify code that no longer exists.

---

Category 2: Reasoning Parser Bugs

Ref	Type	Title
#38212	Issue	MiniMaxM2ReasoningParser broken for M2.5 (<think> start tag not handled)
#38213	PR	fix(reasoning): MiniMaxM2ReasoningParser broken for M2.5
#44898	PR	Fix MiniMax M2 reasoning parser leaking re-emitted </think> into content

Does PR #45701 fix these? YES — both bugs.

#38212 / #38213 — M2.5 generates both <think> and </think>, but the old parser assumed only </think>. The engine config handles both:

(ParserState.REASONING, "THINK_START"): Transition(ParserState.REASONING, ())  # silently consumed

Starting in REASONING, <think> is consumed with no event. Works for M2 (no start tag) and M2.5 (both tags). PR #38213 is superseded.

#44898 — Re-emitted </think> tokens leaked into content. The engine config handles this:

(ParserState.CONTENT, "THINK_END"): Transition(ParserState.CONTENT, ())  # silently consumed

Any </think> in CONTENT state is consumed without emission. PR #44898 is superseded.

---

Category 3: Reasoning Token Accounting

Ref	Type	Title
#37988	Issue	minimax-m2.5, reasoning token result in negative values
#37955	PR	Fix reasoning_tokens accounting for MiniMax M2

Does PR #45701 fix these? PARTIALLY.

The engine's count_reasoning_tokens() correctly counts tokens between <think> and </think> using depth tracking. However, #37988 may be about the serving layer's accounting logic (how completion_tokens_details.reasoning_tokens is computed), not the parser itself.

PR #37955 addresses a different layer and is NOT superseded — it may still be needed.

---

Category 4: Missing adjust_request / Special Token Handling

Ref	Type	Title
#42307	PR	Add missing adjust_request to MinimaxM2ToolParser

Does PR #45701 fix this? YES.

The engine adapter chain provides adjust_request() automatically — ParserEngineToolAdapter.adjust_request() calls super().adjust_request(request) then self._parser_engine.adjust_request(request), which sets skip_special_tokens = False. PR #42307 is superseded.

---

Category 5: Function Name Validation (Hallucinated Tool Calls)

Ref	Type	Title
#37790	PR	Fix MiniMax-M2 parser failed to validate function names

Does PR #45701 fix this? YES — new in the updated PR.

The config sets validate_tool_names=True, and the engine now has _is_valid_tool_name() which calls find_tool_name() to check whether a function name exists in request.tools. Validation is enforced at three points:

• _emit_name_delta() — streaming: skip invalid name deltas
• _handle_tool_end() — streaming: skip invalid tool at invoke end
• _build_extracted_result() — non-streaming: exclude invalid tool calls
  The _tools list is synced from the request via _check_skip_tool_parsing(), which now also sets self._tools = tools.

New tests confirm this works:

• test_invalid_tool_name_is_rejected — img_gen rejected when only search is in tools
• test_mixed_tool_names_only_return_valid — only valid calls returned from mixed output
• test_streaming_invalid_tool_name_is_rejected — streaming path also rejects

PR #37790 is superseded.