Alanxtl opened a new issue, #3445:
URL: https://github.com/apache/dubbo-go/issues/3445
### Problem
Dubbo-go already supports passing request attachments through
`context.WithValue(ctx, constant.AttachmentKey, ...)`. The
`dubbo-go-samples/context` sample covers this direction:
```text
consumer request attachment -> provider ctx.Value(constant.AttachmentKey) ->
business response body
```
However, this does not cover the opposite direction:
```text
provider result attachments -> Triple response trailers -> consumer reads
response attachments
```
For Triple unary calls, provider-side result attachments can be propagated
as response trailers. The missing piece is that generic invocations do not
currently expose a consumer-side API for reading those response trailers.
### Current limitation
`filter/generic.GenericService` currently defines `Invoke` as a function
field without per-call options:
```go
type GenericService struct {
Invoke func(ctx context.Context, methodName string, types []string, args
[]hessian.Object) (any, error) `dubbo:"$invoke"`
}
```
The normal Triple generated unary client path can capture response metadata
with call options, for example:
```go
var trailers http.Header
resp, err := svc.Greet(
ctx,
req,
client.WithResponseTrailer(&trailers),
)
```
But `GenericService.Invoke` has no `opts ...client.CallOption` parameter, so
callers cannot pass `client.WithResponseTrailer(&trailers)` when making a
generic invocation.
### Expected behavior
Generic Triple unary invocations should provide a way to read response
attachments/trailers on the consumer side.
One possible API shape:
```go
var trailers http.Header
result, err := genericService.Invoke(
ctx,
"echo",
[]string{"java.lang.String"},
[]hessian.Object{"hello"},
client.WithResponseTrailer(&trailers),
)
```
`InvokeWithType` should also be able to pass the same call options through:
```go
err := genericService.InvokeWithType(
ctx,
"getUser",
[]string{"java.lang.String"},
[]hessian.Object{"123"},
&user,
client.WithResponseTrailer(&trailers),
)
```
### Suggested implementation direction
- Add `opts ...client.CallOption` to `GenericService.Invoke` and
`InvokeWithType`.
- Teach the proxy reflection path to recognize and strip optional
`client.CallOption` values from the service method arguments.
- Preserve those call options when constructing the invocation, using the
same response metadata attribute path as generated unary clients
(`ResponseHeaderKey` / `ResponseTrailerKey`).
- Avoid introducing a second mechanism that reads response trailers back
from the original `context.Context`; the existing unary client call option path
should be reused.
### Why this matters
Without this, the request attachment path is usable, but generic callers
cannot read provider response attachments from Triple response trailers.
Documentation should describe the supported direction clearly, and the generic
API should expose the same response metadata capture capability available to
generated unary clients.
--
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]
