Qt GRPC: Why is handling a response required for a grpc call?
-
I've recently been working with Qt Grpc in 6.8.1 in C++, following along the Client Guide Example:
std::unique_ptr<QGrpcCallReply> reply = m_client.UnaryCall(requestMessage); const auto *replyPtr = reply.get(); // 1 QObject::connect( replyPtr, &QGrpcCallReply::finished, replyPtr, [reply = std::move(reply)](const QGrpcStatus &status) { ... }, Qt::SingleShotConnection // 2 );
I was able to get the example to work. However, I noticed that if I omitted the code which handles the response, my server would not receive any call. Specifically, just
std::unique_ptr<QGrpcCallReply> reply = m_client.UnaryCall(requestMessage);
would not execute a grpc call that my server received. Why? In the full example above, does the call get executed when QObject::connect is called?
I understand that the vast majority of the time, we need to check the response to gain information so this is an edge case. I am curious why the code didn't behave as I expected.
-
std::unique_ptr<QGrpcCallReply> reply = m_client.UnaryCall(requestMessage);
I would guess you should think about how long this object is alive.
-
You indeed answered to your own question. If nothing supposed to receive the response, request is ignored in case is there is no active channel established to the server. And this can happen if the call happens in the same stack with QGrpcHttp2Channel ctor.
I think we may make this behavior controllable, so add the call option that allows always "no-discard" calls.
-
Hey, as our docs state: "Users are responsible for managing the unique RPC handlers returned by the Client interface", the RPC object has to be alive to continue any processing. You don't need to connect to finish but it's highly recommended since you don't know when the time for deletion would be.