Oxidaner opened a new issue, #3715: URL: https://github.com/apache/dubbo-go/issues/3715
### Problem dubbo-go still accepts legacy net/rpc-shaped methods such as: ```go func Fetch(ctx context.Context, req *Request, reply *Response) error ``` Today `suiteMethod` treats both pointers as ordinary input arguments, while the provider response is built only from declared Go return values. Mutating `reply` therefore does not send that value back to the caller. Interface-level metadata accurately exposes the current runtime shape as two inputs plus `void`, so Dubbo Admin generic invocation cannot recover an intended reply value either. A trailing-pointer heuristic is not safe: a legitimate void method such as `func Transfer(ctx context.Context, from *Account, to *Account) error` has the same reflection shape. ### Proposed direction Add explicit method-level metadata or a registration option that marks an argument as the response slot. Do not infer output direction from pointer position alone. When explicitly declared, the complete call chain should: - model the marked argument as the method return in service definitions; - serialize the provider-side mutated value as the RPC response; - make direct and generic clients receive that response; - preserve existing unmarked multi-pointer void methods without changing their arity or behavior. The API location still needs design work, likely around `ServiceInfo.MethodInfo` or service registration options. ### Acceptance criteria - No trailing-pointer heuristic or false-positive behavior change. - Explicit reply metadata survives registration into the runtime method model. - Provider response handling returns the marked argument. - Interface-level definitions expose the marked type as `returnType`, not as an extra input. - Generic invocation through Dubbo Admin receives the response. - Tests cover net/rpc-style replies and legitimate multi-pointer inputs. Related to #3499 and PR #3711. -- 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]
