[Web] Fix RPC argument parsing for new FFI string/bytes types

[guan404ming]

Why

Recent FFI refactoring added new type indices kTVMFFIStr (65) and kTVMFFIBytes (66). The RPC server didn't
handle these, causing "cannot support type index 65/66" errors when Python sends string/bytes arguments via
RPC.

How

WriteFFIAny in C++ writes the type_index twice for these types. The fix adds handlers that read and discard the duplicate type_index before reading the actual data.

[gemini-code-assist]

Summary of Changes

Hello @guan404ming, 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 resolves a critical compatibility issue in the RPC server by enabling it to correctly handle recently introduced FFI string and bytes data types. By adding specific parsing logic for these new types, it ensures seamless communication when Python clients send string or byte arguments via RPC, thereby preventing runtime errors and maintaining system integrity.

Highlights

• RPC Argument Parsing Fix: Addresses an issue where the RPC server failed to correctly parse new FFI string and bytes types, which were causing 'cannot support type index 65/66' errors.
• New FFI Type Support: Introduces explicit handling for kTVMFFIStr (type index 65) and kTVMFFIBytes (type index 66), ensuring compatibility with recent FFI refactoring.
• Duplicate Type Index Handling: Implements logic to skip a duplicate type_index that is written by WriteFFIAny for these new string and bytes types, allowing for correct data deserialization.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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 addresses an issue where the RPC server was not correctly handling new FFI string/bytes types (kTVMFFIStr and kTVMFFIBytes) introduced in a recent FFI refactoring. The fix involves adding handlers to read and discard the duplicate type_index written by WriteFFIAny in C++ for these types. The changes are straightforward and seem to resolve the reported issue.

[guan404ming]

I've confirmed that the C++ side does indeed write the type_index twice for kTVMFFIStr and kTVMFFIBytes. The flow is:

1. SendPackedSeq (in rpc_reference.h:314) writes type_index for each argument
2. For kTVMFFIStr/kTVMFFIBytes, it falls through to the default case which calls WriteFFIAny
3. WriteFFIAny (in rpc_endpoint.cc:237-243) writes the type_index again before the size and data

So the wire format for these types is: type_index(u32) | type_index(u32) | size(u64) | data The TypeScript fix correctly handles this by reading and discarding the duplicate type_index.

[guan404ming]

cc @junrushao

[junrushao]

LGTM