Both the RPC and in-process resolvers lack an explicit application-level delay before re-establishing the stream after an error or completion. They rely entirely on gRPC channel-level mechanisms (wait_for_ready, channel backoff options), which don't prevent tight loops when the stream itself errors immediately (e.g., an intervening L7 proxy returning errors on stream creation).
Per the provider spec, providers must apply an explicit application-level delay of retryBackoffMaxMs before re-establishing the stream. All other provider implementations (Go, Java, JS, .NET) already do this.
Affected resolvers:
resolvers/grpc.py (RPC)process/connector/grpc_watcher.py (in-process)
Both the RPC and in-process resolvers lack an explicit application-level delay before re-establishing the stream after an error or completion. They rely entirely on gRPC channel-level mechanisms (
wait_for_ready, channel backoff options), which don't prevent tight loops when the stream itself errors immediately (e.g., an intervening L7 proxy returning errors on stream creation).Per the provider spec, providers must apply an explicit application-level delay of
retryBackoffMaxMsbefore re-establishing the stream. All other provider implementations (Go, Java, JS, .NET) already do this.Affected resolvers:
resolvers/grpc.py(RPC)process/connector/grpc_watcher.py(in-process)