[Bugfix] Fix Kimi-K2 tool parser streaming regex for multiple tool calls

[karanb192]

Summary

• Fix the streaming regex patterns in Kimi-K2 tool parser to correctly handle multiple concatenated tool calls
• The bug was that the streaming regexes used .+ which greedily matched across tool call boundaries, causing multiple tool calls to be incorrectly merged into a single malformed entry
• The fix changes .+ to [^<]+ in stream_tool_call_portion_regex and stream_tool_call_name_regex to match the non-streaming regex behavior

Related Issue

Fixes #24478

Root Cause

The streaming tool call regexes used .+ pattern which matches ANY character including <. When multiple tool calls were concatenated without spacing (e.g., <|tool_call_end|><|tool_call_begin|>), the greedy .+ would match across tool call boundaries, capturing content like:

functions.get_weather:0<|tool_call_argument_begin|>{"lat":34}<|tool_call_end|><|tool_call_begin|>functions.get_news:1

This resulted in a garbled tool call ID and mismatched arguments as shown in the issue.

Fix

Changed .+ to [^<]+ which excludes < characters. This ensures the regex stops at the first < (the start of the next special marker), preventing over-matching. This matches the behavior of the non-streaming regex which already used [^<]+.

Test Plan

• Added test_streaming_regex_does_not_match_across_tool_boundaries: Unit test that directly validates the regex patterns correctly stop at < characters
• Added test_streaming_concatenated_tool_calls_issue_24478: Regression test that simulates the exact scenario from the bug report

Run tests:

pytest tests/tool_parsers/test_kimi_k2_tool_parser.py -v

[gemini-code-assist]

Code Review

This is an excellent bug fix. The pull request description clearly explains the root cause of the issue—a greedy regex .+ causing multiple tool calls to be merged—and the fix of using [^<]+ is correct and effective. The addition of two new tests, one unit test for the regex and one regression test for the streaming behavior, is very thorough and ensures this bug will not reappear. I have a couple of suggestions to make the new tests even more robust by asserting that a regex match occurs where expected, preventing silent test passes. Overall, great work!

[gemini-code-assist]

The if match: condition could mask a potential issue. If portion_regex.match() were to return None (for example, due to a future change in the regex), this test would pass silently without executing the assertions. It's better to explicitly assert that a match is found when one is expected.

Suggested change

	if match:
	# If it matches, it should only capture up to the first '<'
	tool_id = match.group("tool_call_id")
	# The tool_id should NOT contain special markers
	assert "<|" not in tool_id, (
	f"Regex over-matched across tool boundaries! "
	f"Captured tool_id: {repr(tool_id)}"
	)
	assert tool_id == "functions.get_weather:0", (
	f"Expected 'functions.get_weather:0', got: {repr(tool_id)}"
	)
	assert match is not None, "The regex is expected to match the problematic input."
	# If it matches, it should only capture up to the first '<'
	tool_id = match.group("tool_call_id")
	# The tool_id should NOT contain special markers
	assert "<|" not in tool_id, (
	f"Regex over-matched across tool boundaries! "
	f"Captured tool_id: {repr(tool_id)}"
	)
	assert tool_id == "functions.get_weather:0", (
	f"Expected 'functions.get_weather:0', got: {repr(tool_id)}"
	)

[gemini-code-assist]

Similar to the previous comment, using if name_match2: can hide a potential failure if the regex doesn't match as expected. The test would pass silently. It's more robust to assert that a match is found.

Suggested change

	if name_match2:
	# Should stop at '<' if using [^<]+
	captured_id = name_match2.group("tool_call_id")
	assert "<|" not in captured_id, (
	f"Name regex over-matched! Captured: {repr(captured_id)}"
	)
	assert name_match2 is not None, "The name_regex is expected to match."
	# Should stop at '<' if using [^<]+
	captured_id = name_match2.group("tool_call_id")
	assert "<|" not in captured_id, (
	f"Name regex over-matched! Captured: {repr(captured_id)}"
	)

[karanb192]

Hi @DarkLight1337 - could you please review this tool parser fix? It addresses issue #24478 where the Kimi-K2 parser had a streaming regex failure. Thanks!

[DarkLight1337]

cc @chaunceyjiang

[ehfd]

@chaunceyjiang I think this is relevant.