Messages logged when timeouts are active do not respect current log level #5395
Comments
|
Interesting bug. The reason why it occurred was this:
Delaying messages makes sense, #2839 had a critical priority for a reason, but the current approach to do that in the central |
Previous messages weren't restored meaning that messages could be lost. The unused variable also made linters unhappy. This code attemps to avoid problems with timeouts interrupting writing to output files. The current code was written to fix #5395 and is basically a rewrite of the fix for #2839. As #5417 explains, there are still problems and bigger changes are needed.
|
This issue had been reported already in 2019 (#3336), but back then I thought fixing it would be much more complicated than it was. The logging related code has been heavily refactored since then and it could be that it would have been harder then, though. This issue also has exactly the same root cause as #3644 and that problem has now been fixed as well. I'll still add tests to validate that, though. |
Hi Peke,
When using
BuiltIn().set_log_level("NONE")during a keyword execution in the keyword implementation or inrun_keywordof a dynamic library, this has no effect on the logging happening subsequently in that keyword.Concrete use case is, that i want to set a suite variable in run_keyword when an error happens, but that setting of the variable shall not be logged.
So i set the log level to None and then to the original back, after setting the variable.
Unfortunately the setting of the variable is still being loggen, IF a
[Timeout]is in use.See the Reproduction.zip to do reproduce.
Reproduction.zip
afaik if a timeout is active, the actual keyword call is in a thread and therefore it does not effect the log_level?
The text was updated successfully, but these errors were encountered: