About expected timeouts

Hi,

I’m a newb with respect to both Robot Framework.

I’m writing a test procedure that is expected to

connect to another machine
perform an image update (which causes the unit to close all services and reboot itself)
re-connect to the unit
run a command that returns a known string.

This is all supposed to happen within the init.robot module

What I have noticed is that I must invoke the upgrade procedure in a synchronous, or blocking way, like so

Execute Command    sysupgrade upgrade.img

This succeeds in upgrading the unit, but the robotframework script hangs executing the command. I suspect this works because it keeps the ssh session alive long enough for the upgrade to reach a critical junction where the session is closed by the remote host, the upgrade continues and this does not cause the upgrade to fail.

But the remote host appears to close the ssh session in such a way that the robotframework script does not detect it, and the script hangs indefinitely.

Trying to work around this, I tried invoking the remote command like so

Execute Command    sysupgrade upgrade.img &

But then the update fails because the connection appear to drop and leaves the upgrade procedure incomplete.

If instead I execute it like this

Execute Command    sysupgrade upgrade.img &
Sleep    600

Then this also fails, for some reason I am unable to deduce.

However, if I invoke it like this

Execute Command    sysupgrade upgrade.img    timeout=600

The the command succeeds in updating the unit, and after the set timeout period, the robotframework script does indeed resume, but since it has arrived at the timeout, the test has (from the point of view of robotframework) failed.

But this is actually an expected failure, and could be ignored.
The rest of the script would then reconnect to the host and continue the remaining test(s)

Is there a way to treat the timeout condition as non-fatal?

Here is the code, as explained above, the init.robot initialization module is expected to perform the upgrade and then reconnect, leaving the other xyz.robot files to be run and continue testing the applications.

init.robot

*** Settings ***
| Library | OperatingSystem |
| Library | SSHLibrary |
Suite Setup ValidationInit
Suite Teardown ValidationTeardown

*** Keywords ***
ValidationInit
Enable SSH Logging validation.log
Open Connection ${host}
Login ${username} ${password}

Upload the firmware to the unit.

Put File    ${firmware}    upgrade.img    scp=ALL

Perform firmware upgrade on the unit.

log     "Launch upgrade on unit"
${stdout}=    Execute Command    sysupgrade upgrade.img    timeout=600
log     "Restart comms"
Close All Connections
Open Connection    ${host}
Login              ${username}    ${password}

ValidationTeardown
Close All Connections
log “End tests”

Hi Jean,

I would suggest you try Run Keyword And Expect Error

Run Keyword And Expect Error    Execute Command    sysupgrade upgrade.img    timeout=600

Then if it doesn’t reach the timeout (expected condition in this case) your test will fail, otherwise if it times out as expected it will continue as a pass.

There are other variants Run Keyword … to explore, if this one doesn’t fit your scenario.

Hope that helps,

Dave.

Hi Dave!
Thanks for the explanation!

I was able to get a good result doing this instead:

set client configuration  timeout=300
SSHLibrary.Write    sysupgrade upgrade.img
log     "Upgrade performed, Waiting for unit to become ready"
SSHLibrary.Read Until    Rebooting system...

This way, instead of always waiting for the timeout and concluding that it signaled that the operation/upgrade had been successful, this different method actually tracks the execution and ends when the operation/upgrade has indeed concluded.