Current value of timeout=0.1 is sometimes too tight.
Bump timeout to 0.3 to avoid test failures.

Signed-off-by: Saif Abrar <saif.abrar@linux.vnet.ibm.com>
---
 tests/qemu-iotests/tests/iothreads-stream | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/tests/iothreads-stream b/tests/qemu-iotests/tests/iothreads-stream
index 503f221f16..32e46e044e 100755
--- a/tests/qemu-iotests/tests/iothreads-stream
+++ b/tests/qemu-iotests/tests/iothreads-stream
@@ -63,7 +63,7 @@ with iotests.FilePath('disk1.img') as base1_path, \
     finished = 0
     while True:
         try:
-            ev = vm.event_wait('JOB_STATUS_CHANGE', timeout=0.1)
+            ev = vm.event_wait('JOB_STATUS_CHANGE', timeout=0.3)
             if ev is not None and ev['data']['status'] == 'null':
                 finished += 1
                 # The test is done once both jobs are gone
-- 
2.31.1

Am 24.01.2024 um 14:35 hat Saif Abrar geschrieben:
> Current value of timeout=0.1 is sometimes too tight.
> Bump timeout to 0.3 to avoid test failures.
> 
> Signed-off-by: Saif Abrar <saif.abrar@linux.vnet.ibm.com>

This is not the real problem. The real problem is that the timeout makes
the test fail because we're catching the wrong TimeoutError class. What
it really should do is issue another query-jobs and go back to waiting.

I actually sent a patch earlier today to fix this:

https://lists.gnu.org/archive/html/qemu-block/2024-01/msg00353.html

Kevin