Potential Issue with `continuation` in `enqueue(waitForReady:)` not resuming

[mohammad-volvo]

I’m encountering a situation—possibly due to a misconfiguration on my end—where the continuation of the private func enqueue(waitForReady: Bool) async throws -> LoadBalancer function in GRPCChannel.swift never resumes. As a result, the caller is left hanging indefinitely without any error or feedback.

I’m not certain if this is a bug or a result of incorrect usage, but I wanted to raise it as something that could be handled more gracefully.

[glbrntt]

The continuation should resolve eventually. Do you have more details on how to reproduce this?

[alecb-stripe]

I believe I'm running into this too. I think the issue is that the continuations enqueued here:

grpc-swift-nio-transport/Sources/GRPCNIOTransportCore/Client/Connection/GRPCChannel.swift

Line 347 in 0393731

state.enqueue(continuation: continuation, waitForReady: waitForReady, id: id)

are never being resumed, I believe because the channel they're waiting for never gets to a ready state:

grpc-swift-nio-transport/Sources/GRPCNIOTransportCore/Client/Connection/GRPCChannel.swift

Lines 782 to 788 in 0393731

	case .ready:
	// Current load-balancer became ready; resume all continuations in the queue.
	let continuations = state.queue.removeAll()
	actions.resumeContinuations = ConnectivityStateChangeActions.ResumableContinuations(
	continuations: continuations,
	result: .success(state.current)
	)

---

I don't have a complete minimal repro, but for context, essentially all I'm trying to do is making a gRPC call over a unix domain socket:

let client = Some_Grpc_Service.Client(
    wrapping: GRPCClient(
        transport: try! .http2NIOPosix(
            target: .unixDomainSocket(path: socket),
            transportSecurity: .plaintext
        ),
    ))

var options = CallOptions.defaults
// options.timeout = .seconds(60)
options.waitForReady = true

try await client.someGrpcMethod(
    request: ClientRequest(message: request), options: options)

This hangs indefinitely (unless I set the timeout).

[glbrntt]

I don't think you're hitting the same problem: you need to call runConnections() on the client or use withGRPCClient.

[alecb-stripe]

Figured that out eventually as well! But how do we know that's not the same problem @mohammad-volvo was facing?

Whether it was the same underlying issue or not, I think I echo the sentiment here:

I’m not certain if this is a bug or a result of incorrect usage, but I wanted to raise it as something that could be handled more gracefully.