Streaming Interceptors #3641
Streaming Interceptors #3641
Conversation
…wrapping streaming methods
…plied; import the correct user types packages when rendering service_interceptors.go; fix an ancient typo
…dpoint field from goa.InterceptorInfo struct since it is redundant with the next goa.Endpoint parameter sent to interceptors
…thod with interceptors even if they do not apply
| {{- range .WrappedClientStreams }} | ||
|
|
||
| {{ comment (printf "wrapped%s is a client interceptor wrapper for the %s stream." .Interface .Interface) }} | ||
| type wrapped{{ .Interface }} struct { |
There was a problem hiding this comment.
Might be nice to move the type definition to the top of the file
pkg/interceptor.go
Outdated
| @@ -9,8 +9,10 @@ type ( | |||
| Service string | |||
There was a problem hiding this comment.
We should update the struct header comment to reflect the changes
pkg/interceptor.go
Outdated
| @@ -9,8 +9,10 @@ type ( | |||
| Service string | |||
| // Name of method handling request | |||
| Method string | |||
| // Endpoint of request, can be used for retrying | |||
| Endpoint Endpoint | |||
| // Send is true if the request is a streaming Send | |||
There was a problem hiding this comment.
What's the rationale for these two fields? I could see Send helping differentiate between the initial request and the streaming request in the case of websocket but not sure I understand the point of Recv?
There was a problem hiding this comment.
Let's say you are building an OTel tracing interceptor for a bidirectional stream that needs to send per message trace and span IDs in both directions:
- The interceptor will need to grab the tracing data from the
context.Contextand add it to the message when interceptingSend - The interceptor will need to grab the tracing data from the message and add it to the
context.Contextwhen interceptingRecv
Having both of these fields allows the interceptor to know whether it isSend,Recv, or the initial request.
There was a problem hiding this comment.
Got it, makes sense. I wonder if we could have only one field then?
There was a problem hiding this comment.
I suppose we could replace it with an enum.
There was a problem hiding this comment.
Maybe something like: goa.InterceptorMethod, goa.InterceptorStreamingSend, goa.InterceptorStreamingRecv.
There was a problem hiding this comment.
Yes, goa.InterceptorUnary instead of Method maybe?
…ds with a CallType enum; organize interceptor wrappers file sections as types, functions, then methods
…s to modify the context returned by SendWithContext/RecvWithContext even after calling next
…ace to return a context itself
… info structs implement
SendWithContextandRecvWithContextmethods to the stream interfaces