Async keywords are not stopped when execution is stopped gracefully

[jaltendorfer]

Stop a test execution during an async keyword with SIGINT or CTRL+C. Now the teardown with async keywords is executed, but the test keyword still runs and is not stopped.

Example:

Test python library:

import asyncio
from robot.api.deco import library, keyword
from robot.api import logger


@library
class TestLibrary:

    @keyword(name="Async Sleep")
    async def async_sleep(self, time: int, log_message: str):
        logger.info(f"{log_message} start", also_console=True)
        await asyncio.sleep(time)
        logger.info(f"{log_message} end", also_console=True)

Test robot suite:

*** Settings ***
Library    TestLibrary.py


*** Test Cases ***
Test
    TestLibrary.Async Sleep    ${5}    Sleep Test
    [Teardown]    TestLibrary.Async Sleep    ${10}    Sleep Teardown

Result:

[pekkaklarck]

Teardowns are, by default, executed when execution is gracefully stopped. If you don't want that, you can use the --skip-teardown-on-exit command line option. Does that work for you? Do you see differences with normal and async keywords in this regard?

[jaltendorfer]

The problem is not that the teardown is executed. The problem is, that the async keyword in the test case is not stopped immediately before executing the teardown. In the example result of the post before, you can see the log messages of the test case keyword in the teardown after a graceful stop of the execution.

Normal behaviour with graceful stop:

• Running keyword in the test case is stopped immediately
• Teardowns are executed

Current behaviour when using async keywords:

• Running keyword in the test case is not stopped
• Teardowns are executed and the test case keyword is still running (in background) until completion.

In my example in the post above, you can see the log message "Sleep Test" being logged in the teardown, although the execution was stopped and the testcase keyword should have been stopped immediately (only the teardown should be executed).

[pekkaklarck]

I see. Apparently async methods would need separate handling to get them killed. Would be nice to get that fixed in RF 6.1.2.

I'm on holiday and won't have time to look at this in the near future. If someone with more async knowledge would be interested to look at this already now that would be great. Ping @ygorpontelo.

[ygorpontelo]

We can cancel the coroutines when we receive the graceful stop event. We can also check for running coroutines and better clean ups once we are stopping the run as well. I'll get to it as soon as i can.

[pekkaklarck]

Sorry for forgetting about this. The PR looks good otherwise but we'd also need a test. I hope we could still get this into RF 7.

[pekkaklarck]

After thinking this a bit more, the current behavior is buggy and we believe bugs should in general be fixed as soon as possible. I added this to RF 7 scope. Hopefully you @ygorpontelo can help with tests. Getting somewhat related #4803 into RF 7 would be good too.

[pekkaklarck]

Fixed by PR #4835. Great work @ygorpontelo!