Details
Description
I'm observing a strange behavior in my application. Not sure if it's on my end though or a legit bug.
Setup
- Step 1) make some unary calls
- Step 2) receive server response for each
- Step 3) kill server
- Step 4) `errorOccurred` is emitted for each unary call I made ("QGrpcStatus::Unavailable "Network error occurred 1")
I don't understand why 4) still happens if a response for the reply was received. Doesn't matter how long I wait between 2) and 3) it always happens.
Shouldn't the reply be deleted after a response (for a Unary call at least)?
My signal & slot setup looks like this (not even using QGrpcReply::errorOccurred):
connect(client.get(), &MyService::Client::errorOccurred, this, &MyServiceImpl::errorOccurred); // void MyServiceImpl::errorOccurred(const QGrpcStatus &status) { qCWarning(LOG) << "Connection error occurred" << status.code() << status.message(); }
—
Looking at the source code for the `call` implementation - without understanding the details - this part stands a bit out:
https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/grpc/qabstractgrpcclient.cpp?h=v6.7.0#n220
std::shared_ptr<QGrpcCallReply> QAbstractGrpcClient::call(QLatin1StringView method, QByteArrayView arg, const QGrpcCallOptions &options) { std::shared_ptr<QGrpcCallReply> reply; ... auto errorConnection = std::make_shared<QMetaObject::Connection>(); *errorConnection = connect(reply.get(), &QGrpcCallReply::errorOccurred, this, [this, reply, errorConnection](const QGrpcStatus &status) { QObject::disconnect(*errorConnection); emit errorOccurred(status); }); return reply; }
The errorConnection seems to keep the shared ptr alive indefinitely until an error happens? Is this intended? I'm just guessing here.
—
Either way, please let me know if you need more details and whether my observed behavior is intended or not.