pyportaltests: work around potential session close timeout failures #168
Conversation
|
Thanks, I'll try applying this to the packages where I saw #166 and see what happens. |
|
This isn't solving the issue for me. When I run the test in a loop, I'm variously either seeing success, the same failure mode as before, or a segfault inside libportal. Following up on the segfault is probably the best route, since fixing that might also fix #166. |
|
|
Closing based on #168 (comment) |
whot
force-pushed
the
wip/fight-the-timeouts
branch
from
da5cc13
to
c98b91b
Compare
|
|
whot
force-pushed
the
wip/fight-the-timeouts
branch
from
c98b91b
to
492dea1
Compare
|
Alright, this time it does work. So in the end it was a race condition between when the signal was sent out and when the test registered for the signal. The 500ms simply weren't enough. Yesterday's patch had a bug - to make it nice python I dropped the result but that had the side-effect of Python cleaning up the |
This works around a race condition where test_close_session_signal registers a callback but on slow systems the Close signal may be sent before said callback can be registered. Note that we need to keep the returned SessionResult alive so the XdpSession isn't cleaned up by the Python GC before we finish the test. Closes flatpak#166
whot
force-pushed
the
wip/fight-the-timeouts
branch
from
492dea1
to
e506491
Compare
This may or may not fix #166 but ever optimistically we go for the former.
cc @smcv, @GeorgesStavracas