feat(parser): add tool-input-start/end events to morphXmlProtocol

[biubiupiu1]

Add support for tool-input-start and tool-input-end events in morphXmlProtocol's createStreamParser to track tool call lifecycle. Events are emitted with matching IDs for proper correlation between start, end, and tool-call events.

• Emit tool-input-start when tool opening tag is detected
• Emit tool-input-end when tool parsing completes (success or error)
• Handle incomplete tool calls at stream end
• Add comprehensive test coverage for all scenarios

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @biubiupiu1, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the 'morphXmlProtocol' by integrating new 'tool-input-start' and 'tool-input-end' events. These events provide a more granular view into the lifecycle of tool calls, allowing for better tracking and debugging of when a tool's input processing begins and concludes, regardless of whether the call is successful, fails, or is incomplete.

Highlights

• New Tool Call Lifecycle Events: Introduced 'tool-input-start' and 'tool-input-end' events within the 'morphXmlProtocol' to track the beginning and end of tool call processing.
• Event Correlation: Each 'tool-input-start', 'tool-input-end', and 'tool-call' event now shares a unique 'id' to enable proper correlation and tracking of a single tool call's lifecycle.
• Comprehensive Event Emission: 'tool-input-end' events are now emitted for all tool call outcomes, including successful parsing, parsing errors, and incomplete tool calls detected at the end of the stream.
• Enhanced Test Coverage: A new dedicated test file has been added to thoroughly validate the correct emission and correlation of these new tool input lifecycle events across various scenarios.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces tool-input-start and tool-input-end events to the morphXmlProtocol to better track the lifecycle of tool calls. The changes correctly emit these events for successful, failed, and incomplete tool calls, and a comprehensive set of tests has been added to cover these scenarios. The implementation looks solid.

My review focuses on improving the new test file's type safety and robustness. I've pointed out a few places where as any casts can be replaced with more specific types to make the tests safer and easier to maintain. I also suggested strengthening an assertion to make a test case more precise. Overall, this is a great addition.

[gemini-code-assist]

Using as any should be avoided as it bypasses TypeScript's type safety. Please cast to LanguageModelV2FunctionTool[] instead. You will need to add LanguageModelV2FunctionTool to the import from @ai-sdk/provider at the top of the file.

Suggested change

	] as any;
	] as LanguageModelV2FunctionTool[];

[minpeter]

@biubiupiu1

[gemini-code-assist]

Using as any should be avoided as it bypasses TypeScript's type safety. This is likely a temporary measure because the new stream part types (tool-input-start, tool-input-end) are not yet part of the LanguageModelV2StreamPart union type.

A better approach would be to define local interfaces for these new event types within the test file and cast to those specific types. This improves type safety and makes the test easier to understand.

For example:

interface ToolInputStartPart {
  type: 'tool-input-start';
  id: string;
  toolName: string;
}

// ... then later ...
const toolInputStart = out.find(
  c => c.type === 'tool-input-start'
) as ToolInputStartPart | undefined;

This pattern should be applied to all usages of as any in this file (e.g., lines 113-114, 155-156, and 221-223).

[minpeter]

optional, skip

[gemini-code-assist]

The assertion toBeGreaterThanOrEqual(1) is too lenient for this test case. Given the input stream contains two distinct tool calls, it would be more precise to assert that exactly two of each event type are found. This will make the test more robust against regressions where one of the tool calls might be missed during parsing.

Suggested change

	expect(toolInputStarts.length).toBeGreaterThanOrEqual(1);
	expect(toolInputEnds.length).toBeGreaterThanOrEqual(1);
	expect(toolCalls.length).toBeGreaterThanOrEqual(1);
	expect(toolInputStarts.length).toBe(2);
	expect(toolInputEnds.length).toBe(2);
	expect(toolCalls.length).toBe(2);

[minpeter]

@biubiupiu1 WDYT?

[Copilot]

Pull Request Overview

This PR adds support for tracking tool call lifecycle events in morphXmlProtocol by introducing tool-input-start and tool-input-end events. These events are emitted during stream parsing to provide visibility into when tool input processing begins and completes.

• Emit tool-input-start when tool opening tag is detected during streaming
• Emit tool-input-end when tool parsing completes (both success and error cases)
• Handle incomplete tool calls at stream end by emitting appropriate events
• Add comprehensive test coverage for all tool input event scenarios

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
packages/parser/src/protocols/morph-xml-protocol.ts	Adds tool-input-start/end event emission logic and updates currentToolCall structure to include ID
packages/parser/tests/protocols/xml-protocol.stream.input-events.test.ts	Adds comprehensive test coverage for tool input events in various scenarios

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[minpeter]

@biubiupiu1 Thank you for your contribution. Please review Gemini's feedback; everything else is LGTM.

(Optional) Add a changeset via patch if you want.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.43%. Comparing base (cd7f94f) to head (3eef58b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #91      +/-   ##
==========================================
+ Coverage   73.28%   73.43%   +0.14%     
==========================================
  Files          17       17              
  Lines         921      926       +5     
  Branches      271      271              
==========================================
+ Hits          675      680       +5     
  Misses        166      166              
  Partials       80       80              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.