Closed wowka1319 closed 1 year ago
You need to change TDLib verbosity level using: https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1set_log_verbosity_level.html.
Ok. But what does the first parameter in td_set_log_message_callback
do?
The max verbosity level that can be logged with the specified callback.
Got it. That is, given the implementation of the callback, level=2 doesn't matter and 0 would be enough?
@log_message_callback_type
def on_log_message_callback(verbosity_level, message):
if verbosity_level == 0:
sys.exit('TDLib fatal error: %r' % message)
_td_set_log_message_callback(2, on_log_message_callback) # -> _td_set_log_message_callback(0, on_log_message_callback)
@wowka1319 Most likely, you don't need a callback for log messages at all.
Instead you need to use setLogVerbosityLevel
and setLogStream
methods to set up logging.
Ok. In your example the callback allows handle fatal error. What happens when fatal error if no that callback with sys.exit(1)
?
I got special update when calling td_receive()
?
All logs including fatal error will be logged to the specified stream using setLogStream
.
And TDLib will crash in case of fatal error. You won't receive any special update using td_receive()
.
Just crashing? Then why is sys.exit("...")
in the example?:
@log_message_callback_type
def on_log_message_callback(verbosity_level, message):
if verbosity_level == 0:
sys.exit('TDLib fatal error: %r' % message)
I suspect a fatal error brings the client into an incorrect state without crashing. Or it doesn't? And TDLib client instance must be closed before application termination to ensure data consistency
I suspect a fatal error brings the client into an incorrect state without crashing.
Yes, sys.exit
is to exit the program because TDLib is already crashed and interacting with TDLib while it already crashed can result Segmentation fault
.
And TDLib client instance must be closed before application termination to ensure data consistency
This is for normal active instance not crashed one.
When crashing of C++ code (caused by incorrect working with memory for example) there's no chance to stop the application gracefully. That's why it's impossible to log that error. But I see that message as a fatal error. That means handling that case is possible without crashing my python app: recreate a client and so on. I think developers provided this opportunity. Or not?
Fatal errors are errors that can't be handled without crashing. The process will be terminated anyway right after the callback returns.
Thanks guys!
I set loglevel=1 (FATAL+ERROR):
but I'm watching too much logs. I guess the most ones is not ERROR/FATAL. Example:
Begin to wait for updates with timeout 1.000000