Unary call to wrapped COM API classes ends in deadlock of the service VI

[Celemen]

I have a gRPC server that wraps a COM API. This COM API has a very large feature set with multiple classes.
The generation of the gRPC client worked only by splitting the proto file into several small parts, which were convertible for themselves (memory error for the whole file). Probably there were no handles left, because the project now has over 2000 typedefs and over 1000 service VIs.
Now I have the problem that I can only call services successfully that are in the main class (Application). For all other classes or when trying to get a reference to another class, the unary call goes into a deadlock. When the COM interface returns an object, the gRPC server returns a unique random 64-bit object id for it instead. This is used for communication. But not for static (permanently existing) objects.
What could be the reason for this? And is the error more on the client side or in the server implementation? We are grateful for any advice and help.

[BShermanator]

I can only speak for "the unary call goes into a deadlock"

I recently submitted a change detailed here: #72

Deadlocks occurred in my application if function calls in the labview_grpc_server.dll failed (for example I gave an invalid ID number), the "Wait On Occurrence" VI would wait for ever. Only way to stop the code was to use the abort button.

[AndrewHeim]

A possible solution is related to #193 , though it's hard to tell on this issue.. I don't have a LV 2019 environment right now, but this fix works locally for me related to #320 .