CAICAIIs opened a new pull request, #3752: URL: https://github.com/apache/dubbo-go/pull/3752
### Description Fixes #3751 A caller without generated stubs reaches a triple service through the `$invoke` procedure, and `client.NewGenericService` always builds such a caller: it forces `WithIDL(constant.NONIDL)` and `WithGeneric()`, and the proxy turns the `dubbo:"$invoke"` tag on `GenericService.Invoke` into the invocation name. Triple dispatches by procedure path, so the provider has to expose `/<interface>/$invoke`; otherwise the route mux answers `404 Not Found` and no invocation is created, which means the `generic_service` provider filter never runs. That procedure is registered for non-IDL exports only. `registerServiceHandlers` appends `buildGenericMethodInfo()` inside `createServiceInfoWithReflection`, which is reached when the service carries no `ServiceInfo`. An IDL-exported service describes its methods in `ServiceInfo`, so `handleServiceWithInfo` registers the declared methods and nothing else, and a generic call to it fails at the router. This change registers the generic entry for the IDL branch as well. | Location | Change | | --- | --- | | [`protocol/triple/server.go`](https://github.com/apache/dubbo-go/blob/develop/protocol/triple/server.go) | `registerServiceHandlers` also registers `/<interface>/$invoke` when `info != nil`, using the existing `buildGenericMethodInfo()` | | [`protocol/triple/server.go`](https://github.com/apache/dubbo-go/blob/develop/protocol/triple/server.go) | `declaresGenericMethod` skips that registration when the service declares `$invoke` itself, so an explicit handler is never replaced | | [`protocol/triple/server_test.go`](https://github.com/apache/dubbo-go/blob/develop/protocol/triple/server_test.go) | unit coverage: an IDL export exposes the declared method and the generic entry, and `declaresGenericMethod` recognizes a declared `$invoke` | | `server/triple_idl_generic_invoke_test.go` (new file) | end-to-end coverage: an IDL-exported protobuf service invoked through `$invoke` by a stub-less client | `saveServiceInfo` is deliberately untouched, so the registry, reflection and OpenAPI metadata of an IDL service keep listing only the methods the service declares. The handler is registered directly through `registerMethodHandler(joinProcedure(intfName, constant.Generic), ...)` instead of being appended to `info.Methods`. ### Verification Unit tests, on the affected packages: ``` $ go test ./protocol/triple/... ./filter/generic/... ./server/... -count=1 ok dubbo.apache.org/dubbo-go/v3/protocol/triple ok dubbo.apache.org/dubbo-go/v3/protocol/triple/triple_protocol ok dubbo.apache.org/dubbo-go/v3/filter/generic ok dubbo.apache.org/dubbo-go/v3/filter/generic/generalizer ok dubbo.apache.org/dubbo-go/v3/server ``` End-to-end: `TestIDLServiceServesGenericInvocation` exports a provider whose method signature is protobuf (`SayHello(*emptypb.Empty) (*wrapperspb.StringValue, error)`) together with a `ServiceInfo`, then calls it with `NewGenericService(..., WithProtocolTriple(), WithGenericType("protobuf-json"), WithURL("tri://127.0.0.1:<port>"))`. It passes with this change and fails without it: disabling the new registration makes the same test fail on every attempt, because the call never reaches the service. `make check-fmt` passes. ### Notes - The provider has to declare the generic serialization (`serialization: hessian2`) for generic calls, exactly as a non-IDL export does today. Generic requests travel as a `TripleRequestWrapper` with an inner hessian2 payload, and the server decodes them through the codec registered from the provider's declared serialization. The end-to-end test sets it explicitly. - Scope is unary (`buildGenericMethodInfo` registers `CallUnary`); streaming generic invocation is not part of this change. - No client-side API change, and the non-IDL path is untouched. ### Checklist - [x] I confirm the target branch is `develop` - [x] I have run `make check-fmt` to verify formatting - [x] I have run the tests for the affected packages (see Verification) - [x] I have added tests that prove my fix is effective -- 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]
