Tests remain sensitive to timing when on slower hardware about go-dqlite HOT 5 OPEN

I would expect #170 and #168 to help a lot in that case too, especially the first one.

from go-dqlite.

#170 does indeed help, although I still get random test failures on my RaspberryPi. I ran 20 builds using sbuild (so each run is in a clean, fresh environment), and only 2 runs passed all tests. The others all had at least one test failure. On my normal build server (amd64), there's absolutely no issues with the tests passing run after run.

from go-dqlite.

I think it has to do with the tls implementation in older go versions, can you (if you have time) experiment with go version 1.17 and see if you see the same behaviour? I'm not quite sure how to go forward, maybe I won't use tls on armhf in the tests and accept it's going to be slow, or search for a faster tls library.

from go-dqlite.

This weekend I built v1.10.2 of this library on an arm64 system (RaspberryPi 3B), running Debian unstable and golang v1.17.5. I performed 25 builds, using sbuild, and observed the following tests failing. (None of the builds had all tests pass.)

• TestClient_Dump (11x)
• TestClient_Transfer (9x)
• TestClient_Transfer (1x)
• TestHandover_TransferLeadership (2x)
• TestIntegration_ExecBindError (2x)
• TestIntegration_LeadershipTransfer (2x)
• TestMembership (9x)
• TestNew_ClusteredKvReadWrite (11x)
• TestNew_ClusteredTimeout (11x)
• TestNew_Default (1x)
• TestNew_KvReadWrite (1x)
• TestProtocol_RequestWithDynamicBuffer (21x)
• TestRolesAdjustment_ReplaceVoterHonorFailureDomain (1x)
• TestRolesAdjustment_ReplaceVoterHonorWeight (1x)

from go-dqlite.

Assign

from go-dqlite.