Node GRPC: Please Help a Newbie w Client Interceptors

[R L]

Hi friends, and well wishes to anyone reading this post.

I'm currently working to instrument some kind of logging / tracing on the client side for our GRPC requests.

I've been reading this proposal and would like to level set some of my understandings so far.

So first--  the nature of a client unary interceptor, as I understand it, is that we can add modifications such as injecting client metadata before the request is sent to the server.

The proposal mentions such things as "inbound" and "outbound" operations.

Question 1: When a GRPC call is being made, are there two streams being opened? Outbound being the stream opened because of the request sent BY the client, and Inbound being the stream opened to return the result by the server? 

So, the listener methods such as `onReceiveMetadata(metadata, next)` are "inbound" in that sense? And it is correct to say that by the time we receive these inbound operations, whatever processing that is done within the function call is "done", and we are just intercepting the entirety of the response as it comes in?

Question 2: At the time of a call being made by the client, we can pass in interceptors like so:

```

client.myCall(message, { interceptors: [interceptor] });

```

Is there a practical example for how someone might want to pass in a list of interceptors when a call is made?

Question 3: In a scenario where the client thinks it sent a message, but the server never receives / acknowledges the request, what happens? (Maybe network went down because of network gremlins), would the pipe close with a stream timeout of `DEADLINE_EXCEEDED` error code?

Question 4: Similar to this question, in the scenario where the stream is not closed but the message is never received by the client- a way to "triage" this would be to add timers earlier in the interceptor stack, and see that the listener method "onRecieveMessage()" for example, was never called.

Feedback, pointers, and links towards any extra reading would all be appreciated!

Thanks,

Rachel

 

[Michael Lumish]

1. We generally consider a single call to be a single stream in which messages and metadata are sent both from the client to the server and from the server to the client. In general, requests and responses can be separated in time, and there can even be back-and-forth interactions in a single stream before a call ends, but in the case of a unary call in particular, the end user sees the incoming metadata as one event, and the rest of the response as another single event. The interceptor API makes no distinction between unary and streaming requests, so it always sees those events separately.

2. The client interceptors proposal you linked has examples of creating and using interceptors. If that doesn't have what you are looking for you will have to be more specific.

3. The client considers a call completed when it receives the status information in the HTTP2 trailers from the server, or the stream is closed some other way. If a client makes a call and never sees it end that way, and the call has a deadline configured, it will create a DEADLINE_EXCEEDED status at that configured deadline. All interceptors and the end user will see that status. If the network connection drops and the client detects it, the call can also end with an UNAVAILABLE status.

4. If a unary request never receives a response message, it should eventually end with a non-OK status, so an interceptor can detect that just by seeing that it has received a status and not a message.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f739dff2-c37d-478a-a499-ff79a8640c05n%40googlegroups.com.