[Python] Fix GRPC_TRACE not working when absl log initialized in cython#41814
[Python] Fix GRPC_TRACE not working when absl log initialized in cython#41814sreenithi wants to merge 13 commits intogrpc:masterfrom
GRPC_TRACE not working when absl log initialized in cython#41814Conversation
|
/gemini-review |
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request correctly fixes an issue where GRPC_TRACE logs were being suppressed after absl::InitializeLog() was introduced. The approach of setting StderrThreshold to INFO before logger initialization is sound. The addition of a test case to verify GRPC_TRACE output is a great improvement. I have one suggestion to make this new test more robust by checking for specific log messages rather than a minimum line count, which can be brittle.
This reverts commit ee0253c.
|
Just for reference, posting the output of the test added in this PR to show that it actually fails without changes in #39779. Test output using
|
| # | ||
| cdef _initialize_absl(): | ||
| if not _disable_absl_init_log: | ||
| SetStderrThreshold(LogSeverityAtLeast.kInfo) |
There was a problem hiding this comment.
Todo: confirm if it should be called before or after InitializeLog()
There was a problem hiding this comment.
That's a good question. I checked it and it looks like there isn't a strict guideline for it. I searched across github and found examples doing both, however calling StdErrorThreshold before InitializeLog seems to be the pattern majority of the time.
Checking further with Gemini's help, here is the rationale behind that:
- Continuity: Before absl::InitializeLog() is called, the library is in a "pre-initialization" state where all log messages are directed to stderr by default, regardless of the threshold.
- Avoid a Logging Gap: Once absl::InitializeLog() is called, the library starts respecting the StderrThreshold (which defaults to kError). If you call InitializeLog() first, there will be a small window of time where INFO and WARNING logs are not sent to stderr until your subsequent call to SetStderrThreshold(absl::LogSeverityAtLeast::kInfo) completes.
- Correctness: Calling SetStderrThreshold() before InitializeLog() ensures that as soon as the library transitions to its initialized state, it is already configured with your desired threshold, resulting in a seamless transition.
From Point 2, I think in this particular case, it's actually fine because we have the calls happening one after another, but in future if we were to have some other code coming in between the calls, it's probably better to have the StdErrThreshold call before InitializeLog to avoid that gap.
|
Do we need default Maybe we could honor |
Thanks, good point. I also checked this after our discussion. First of all, Secondly, for those who continue to use GRPC_VERBOSITY, they can still continue to use it as they already are. Setting to Info level here is not overriding that value. Just verified that by running the helloworld client by setting GRPC_VERBOSITY=error and GRPC_TRACE=api. Because verbosity is grpc/examples/python/helloworld$ GRPC_VERBOSITY=error GRPC_TRACE=api python greeter_client.py
Will try to greet world ...
Traceback (most recent call last):
File "/usr/local/google/home/ssreenithi/my_forks/grpc/examples/python/helloworld/greeter_client.py", line 36, in <module>
run()
File "/usr/local/google/home/ssreenithi/my_forks/grpc/examples/python/helloworld/greeter_client.py", line 30, in run
response = stub.SayHello(helloworld_pb2.HelloRequest(name="you"))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/google/home/ssreenithi/.pyenv/versions/pyvenv_312/lib/python3.12/site-packages/grpc/_channel.py", line 1159, in __call__
return _end_unary_response_blocking(state, call, False, None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/google/home/ssreenithi/.pyenv/versions/pyvenv_312/lib/python3.12/site-packages/grpc/_channel.py", line 990, in _end_unary_response_blocking
raise _InactiveRpcError(state) # pytype: disable=not-instantiable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "failed to connect to all addresses; last error: UNKNOWN: ipv4:127.0.0.1:50051: Failed to connect to remote host: Connection refused"
debug_error_string = "UNKNOWN:Error received from peer {grpc_status:14, grpc_message:"failed to connect to all addresses; last error: UNKNOWN: ipv4:127.0.0.1:50051: Failed to connect to remote host: Connection refused"}"
> |
|
Abseil Default level is If some other library, |
|
Re: #41814 (comment): discussed IRL. We compile with |
GRPC_TRACE not working when absl log initialized in cython
…nt (grpc#41814) Follow up from grpc#39779 that added the absl::InitializeLog() call in Cython. However this set the default STDERR level to error, hence disabling any GRPC_TRACE logs. As discussed in abseil/abseil.github.io#467, the solution is to set the StderrThreshold to INFO to enable the GRPC_TRACE logs. This PR does the same. In addition, a new test that checks for GRPC_TRACE logs is also added. This PR also potentially fixes grpc#41696 Closes grpc#41814 COPYBARA_INTEGRATE_REVIEW=grpc#41814 from sreenithi:absl_init_log_fix_trace 0a8a9cb PiperOrigin-RevId: 881977247
…nt (grpc#41814) Follow up from grpc#39779 that added the absl::InitializeLog() call in Cython. However this set the default STDERR level to error, hence disabling any GRPC_TRACE logs. As discussed in abseil/abseil.github.io#467, the solution is to set the StderrThreshold to INFO to enable the GRPC_TRACE logs. This PR does the same. In addition, a new test that checks for GRPC_TRACE logs is also added. This PR also potentially fixes grpc#41696 Closes grpc#41814 COPYBARA_INTEGRATE_REVIEW=grpc#41814 from sreenithi:absl_init_log_fix_trace 0a8a9cb PiperOrigin-RevId: 881977247
Follow up from #39779 that added the absl::InitializeLog() call in Cython. However this set the default STDERR level to error, hence disabling any GRPC_TRACE logs.
As discussed in abseil/abseil.github.io#467, the solution is to set the StderrThreshold to INFO to enable the GRPC_TRACE logs. This PR does the same.
In addition, a new test that checks for GRPC_TRACE logs is also added.
Related issue: