The related code was changed recently when fixing #5395, but I tested that the same problem occurs also with earlier versions. I noticed this bug by looking at the new code, but I initially couldn't confirm it because there were not problems on Linux.

My understanding on why the bug occurs is this:

• As mentioned in the description, the current mechanism prevents problems by delaying writing log messages. They are written to the output file only after the keyword has finished when timeouts, normally, cannot anymore occur.
• If a library keyword runs other keywords, both the original library keyword and the keyword executed by it have their own timeouts. A timeout killing the parent keyword can thus occur when delayed messages by the child keyword are written.
• The parent keyword could also be killed while other child keyword information (e.g. its documentation) is written. This is not a concern normally and there's no protection for timeouts in these cases.

I believe that fixing this requires a new approach to avoid problems with timeouts interrupting writing to output files. We could try making it possible to pause timeouts whenever we are writing something to an output file, but getting it to work reliably on all operating systems can be challenging. We probably should also make sure no more than one timeout can be active at the same time.

Keywords executing other keywords should actually be registered as "run keyword variants" using the register_run_keyword method. If the above earlier example is changed to this problem doesn't anymore occur:

from robot.api import logger
from robot.libraries.BuiltIn import BuiltIn, register_run_keyword

register_run_keyword(
    library='lib',
    keyword='keyword', 
    deprecation_warning=False
)

MSG = 'A rather long message that is slow to write on the disk. ' * 10000

def keyword():
    while True:
        BuiltIn().run_keyword('Log Huge Message')

def log_huge_message():
    logger.info(MSG)

The problem is that this registration isn't well known and that it should be cleaned up (#2190). Output files getting corrupted is such a severe issue, that I hope we could avoid that also without extra configuration. Anyway, if fixing this problem is too complicated for RF 7.3, we should at least try to enhance the related documentation and make the registration API more well known.

So on Browser and SeleniumLibrary almost all keywords should be registered as run keywords because of their run on failure functionality? Which they are not done, at least on Browser library

Yeah, the run-on-failure functionality uses BuiltIn.run_keyword and is affected by this issue. Registering these keywords as run keywords would mean that timeouts wouldn't be able to stop them and that would probably be worse. This makes fixing this issue even more important.

While investigating this, I noticed that timeouts outside Windows had a bug with nested timeouts (#5422). That explained why this issue occurred only on Windows and after fixing that problem this issue manifested itself also on Linux.

This bug was fixed by pausing timeouts when BuiltIn.run_keyword is used in 00d45d4. The fix in that commit is pretty simple, but figuring out why exactly the problem occurred and what is the best way to fix it was rather complicated. Timeout related code was also refactored pretty heavily in 66d5300 to make the code easier to understand and to ease fixing this issue.

The fix didn't work properly if BuiltIn.run_keyword was used recursively, but that was fixed by the above commits. This fix isn't in RF 7.3 rc 1, but it will be in the final release an in the possible rc 2.