Transport Client and Authentication Interceptors in gRPC Swift v2

[georgebarnett]

You're welcome!

@mat

Regarding the authClient reference, I actually didn't mark it as weak because I can't, the generated Grpc_Auth.Client type is a struct, which understandably gives the error: "'weak' may only be applied to class and class-bound protocol types, not 'Grpc_Auth.Client<HTTP2ClientTransport.TransportServices>'"

Ah yes, good point. Breaking the retain cycle explicitly is my general recommendation for this type of situation anyway.

@mat

As you've mentioned, I'll indeed need to explicitly break the retain cycle, since the Grpc_Auth.Client struct holds a strong reference to the underlying gRPC transport class. My current plan is to keep a reference to the interceptor instance in my high level client class and explicitly break this reference in deinit (I've already tested this successfully). If you have any alternative suggestions or recommendations specifically for this tricky situation, I'd be interested to hear them.

Rather than hold a reference to the interceptor I would tie its lifetime to the lifetime of the connection by calling nil-ing it out after runConnections() returns/throws:

Task { [gRPCTransportClient] in
    defer { 
        authInterceptor.setAuthClient(authClient: nil) 
    }
    try await gRPCTransportClient.runConnections()
    
}

This is quite a natural place to do it as runConnections() will return when the client has shutdown, you then only need to worry about shutting it down at the appropriate time.

@mat

Additionally, not using a Mutex forces me to mark the whole class as @unchecked Sendable, which opens the door to introduce unintended unsafe behaviors.

This is the important bit! It's very easy to accidentally introduce a regression because of @unchecked.