How to figure out which rpc method is throwing an error logged in the ClientErrorDelegate

[CarlosNano]

What are you trying to achieve?

I'm connecting to multiple rpc methods, some are streams and some are not.

Sometimes when I connect to these streams I've got errors in the ClientErrorDelegate, but I can't figure out which rpc is trowing the error.

So I've got two ways of logging the errors:

• When I create the request for each rpc: If I get an error here I would know which one is giving me the error.

• Using the ClientErrorDelegate When I create the service client and and I create the class that provides the channel, I create a logger and I use this class as ClientErrorDelegate:

 var logger = Logger(label: "gRPC", factory: StreamLogHandler.standardOutput(label:))

So in my class I use the extension to log the errors:

extension ClientErrorDelegate {
    
    func didCatchError(_ error: Error, logger: Logger, file: StaticString, line: Int) {
        print("didCatchError, error: \(error), logger: \(logger), StaticString:\(file), line: \(line)")
    }
}

One of the example of this type of error is the following one:

didCatchError, error: handshakeFailed(NIOSSL.BoringSSLError.sslError([Error:  EOF during handshake]))

Is there any way in the delegate to know which method is throwing the error? How come these type of errors are not thrown in the response of the rpc method?

Thanks

[Lukasa]

These errors aren't thrown in the response of the RPC method because grpc-swift abstracts away connection creation. This error is considered non-terminal: it is possible that it will resolve itself, and grpc-swift is going to keep retrying. To throw the error would require us to terminate the RPC, which is not necessary.

Similarly, this error is not associated with one RPC, but all of them: as the connection hasn't come up, none of the RPCs can progress. RPCs are multiplexed onto one connection.

[CarlosNano]

I see, thanks for the response and the extra detail.

I've noticed that sometime I get this error ( a little bit randomly ) and after getting it, grpc retry and returns the response.

What would you suggest is the best way to debug this type of errors? Which classes should I be taking a look first?

Also can the settings for retrying being changed in order to retry more often? It would be awesome if the retry settings can be adjusted to the type of error ( maybe... :) )

Thanks