mochengqian opened a new issue, #3286: URL: https://github.com/apache/dubbo-go/issues/3286
### ⚠️ Verification - [x] I have searched the [issues](https://github.com/apache/dubbo-go/issues) of this repository and believe that this is not a duplicate. ### ✨ Proposal Summary Issue #3259 exposed a real interoperability problem when a dubbo-go service exports a variadic Go RPC method, such as `args ...string`, and the method is consumed from cross-language or generic invocation scenarios. The short-term runtime fix can improve compatibility, but similar problems may still reappear if risky RPC method signatures continue to be introduced without guidance. This proposal suggests adding long-term guidance for variadic RPC methods in cross-language scenarios, including non-blocking warnings, optional tooling support, and clearer recommendations for new service contracts. ### 🛠️ Implementation Approach In short: **The goal is to guide new cross-language services toward safer contracts ([]T, request structs, and Triple + IDL), so similar variadic compatibility issues are less likely to recur.** **Proposal:** I suggest handling this in a non-breaking way and focusing on long-term guidance rather than immediate restriction. 1. Add a non-blocking warning for variadic RPC methods during service export or registration. - If an exported RPC method uses a variadic signature (`...T`), emit a warning. - The warning should explain that variadic RPC methods are fragile in cross-language or generic invocation scenarios. - It should recommend `[]T`, DTO/request structs, or Triple + Protobuf IDL for new services. - This should remain a warning only, not an error. 2. Add optional static analysis or CI tooling. - Provide an analyzer or equivalent tooling to detect exported variadic RPC methods. - The first version can stay simple: detect `...T` in exported RPC/service methods and print migration guidance. - This helps surface the risk during development or CI instead of only at runtime. 3. Add migration guidance for new cross-language services. - Recommend `[]T` instead of `...T` for interface-based definitions. - Recommend request/response structs for more complex inputs. - Recommend Triple + Protobuf IDL for new cross-language services. 4. Document the preferred migration path with a small example. - For example, explain how a method like: `MultiArgs(ctx context.Context, args ...string)` can be replaced by either: `MultiArgs(ctx context.Context, args []string)` or a request struct / IDL-defined repeated field. - The main goal is to reduce runtime ambiguity in cross-language and generic invocation scenarios. ### 📚 Additional Context Temporary solution:PR #3284 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
