Description
Describe the bug
The RPCs start to fail when connectivity changes, e.g. wifi -> cellular, or wifi -> disabled, on/off airplane mode.
The later RPCs all fails, only after restarting the app (recreate a GRPCConnection), the RPC can succeed.
Here is our configuration:
let keepalive = ClientConnectionKeepalive(interval: .seconds(15), timeout: .seconds(10))
let eventLoopGroup = MultiThreadedEventLoopGroup(numberOfThreads: 1)
let channel = GRPCChannelPool.with(
target: .hostAndPort(hostname, port),
transportSecurity: .tls(GRPCTLSConfiguration.makeClientConfigurationBackedByNIOSSL()),
eventLoopGroup: eventLoopGroup
) { configuration in
configuration.keepalive = keepalive
}
Some GRPC tracing log:
A request starts:
12:28:25 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] HTTP2 stream created function:log(level:message:metadata:source:file:function:line:)[130:12]
Some connectivity changes...
12:28:43 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] deactivating connection function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:43 PM VERBOSE <V> [1681845175315102] Logger:[RPC TRACE] scheduling connection attempt function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:43 PM VERBOSE <V> [1681845175315102] Logger:[RPC TRACE] making client bootstrap with event loop group of type SelectableEventLoop function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:43 PM VERBOSE <V> [1681845175315102] Logger:[RPC TRACE] Network.framework is available but the EventLoopGroup is not compatible with NIOTS, falling back to ClientBootstrap function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:43 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] creating a ClientBootstrap function:log(level:message:metadata:source:file:function:line:)[130:12]
Then few pending requests fail:
12:28:43 PM ERROR <E> [1681845175315102] 14 The operation couldn’t be completed.
12:28:43 PM ERROR <E> [1681845175315102] 14 The operation couldn’t be completed.
...
Each new request enqueued continues to show the following GRPC trace logs:
12:28:45 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] enqueued connection waiter function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:46 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] making client bootstrap with event loop group of type SelectableEventLoop function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:46 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] Network.framework is available but the EventLoopGroup is not compatible with NIOTS, falling back to ClientBootstrap function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:46 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] creating a ClientBootstrap function:log(level:message:metadata:source:file:function:line:)[130:12]
12:28:46 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] scheduling connection attempt function:log(level:message:metadata:source:file:function:line:)[130:12]
After connectivity recovers, until the app was forcibly evicted, no RPCs succeeded. The only trace logging we receive from GRPC is is an enqueued connection:
12:31:42 PM VERBOSE <V> [1681845175315102] Logger: [RPC TRACE] enqueued connection waiter function:log(level:message:metadata:source:file:function:line:)[130:12]
grpc-swift version: 1.13.2
Release build
Platform: iOS
To reproduce
This is not 100% reproducible, but quite often reproduced under the connectivity change pattern.
Expected behaviour
The connection can recover when the connectivity is backup.
Please advice is there a certain configuration we can set up on gRPC channel. Or is there a recommended way to restart/manage the GRPC Connection.