sparky8512 / yagrc Goto Github PK

Observed while troubleshooting sparky8512/starlink-grpc-tools#36 (although not actually related to the symptom on that issue):

When a call to yagrc.importer.resolve_lazy_imports fails, for example due to a network issue preventing communication with the reflection service, it leaves the yagrc.importer module state such that a later call then succeeds even when it should fail due to the same cause.

This leads to the caller thinking the import resolution is complete, and if it then attempts to use a supposedly resolved symbol, it will encounter the following error:

AttributeError: attribute access on unresolved lazy module: <attr name>

From a quick look at the yagrc code for this, it looks like it is clearing out the lists of modules to be resolved before doing the actual import resolution, so it will leave them empty regardless of success or failure, and subsequent calls to resolve_lazy_imports will find nothing to do and return without error.

This was observed while investigating sparky8512/starlink-grpc-tools#36, and it does appear to be the culprit of the hang behavior on that issue. See sparky8512/starlink-grpc-tools#36 (comment) for more detail, but the summary is that if the gRPC channel connection is successfully opened, but then network connectivity lost before the reflection queries are completed, this can result in a permanent hang. The particular case where this can happen is when the client does not know connectivity has been lost, because it is not waiting for an ACK in the TCP connection, just more data.

The solution here would be to put timeouts on all the gRPC method calls (the actual RPC calls, not all the calls into the grpc Python code).

As noted in sparky8512/starlink-grpc-tools#81, the google.protobuf.message_factory.MessageFactory class has been deprecated as of a few months ago, so the code in reflector.py that uses it needs to be adjusted to the replacement API.