⚠️ Verification
✨ 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.
-
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.
-
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.
-
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.
-
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
✨ 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.
Add a non-blocking warning for variadic RPC methods during service export or registration.
...T), emit a warning.[]T, DTO/request structs, or Triple + Protobuf IDL for new services.Add optional static analysis or CI tooling.
...Tin exported RPC/service methods and print migration guidance.Add migration guidance for new cross-language services.
[]Tinstead of...Tfor interface-based definitions.Document the preferred migration path with a small example.
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.
📚 Additional Context
Temporary solution:PR #3284