Try to seek for race conditions occurring in Actions only

[bertllll]

I've experienced them more than little times in: Node/masq/communication/communication_manager
at more places in there.

[dnwiebe]

We can move this out of Backlog when we get some specific details about particular tests that fail sometimes but not always in Actions. When you experience that, post a description in a comment here and attach the downloaded console log from Actions.

[bertllll]

I got this despite this area of our code could not be affected by the worked card (GH-381). Happened after a break from seeing any strangely failing tests. When a new Rust version came.

thread 'main' panicked at 'ClientListenerThread could not be restarted: Timeout', D:\a\Node\Node\masq\src\communications\connection_manager.rs:455:23
stack backtrace:
0: 0x7ff74c24187e - std::backtrace_rs::backtrace::dbghelp::trace
test communications::connection_manager::tests::handles_outgoing_fire_and_forget_messages_to_dead_server ... FAILED
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library\std\src....\backtrace\src\backtrace\dbghelp.rs:98
1: 0x7ff74c24187e - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library\std\src....\backtrace\src\backtrace\mod.rs:66
2: 0x7ff74c24187e - std::sys_common::backtrace::_print_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library\std\src\sys_common\backtrace.rs:67

communications::connection_manager::tests::handles_outgoing_fire_and_forget_messages_to_dead_server

[bertllll]

This problem occurred at the same day as the previous but I didn't have time to report it. It showed itself once and in the next run Actions did not complain though I did no changes in the code.

multinode_integration_tests/tests/connection_termination_test

[dnwiebe]

One of the multinode tests failed: provided_and_consumed_services_are_recorded_in_databases.
logs_473.zip

The same test...Bert.
2_Build node on ubuntu-latest.txt

Again
2_Build node on ubuntu-latest.txt

[bertllll]

Windows ...one of node unit tests. No relation to the card being coped (GH-373).

logs_509.zip

[bertllll]

configurator_standard ... setting the gas price

logs_519.zip

[bertllll]

windows: tls_through_node_test (integration); I know this test because that's the one which permanently fails on my Win machine.

logs_530.zip

[bertllll]

MacOS: Node: unit_tests:
initialize_with_clandestine_port_produces_expected_clandestine_discriminator_factories_vector

logs_599.zip

[bertllll]

This is unfortunate. By all evidences, GitHub stopped to support zipped packages and these ours which are attached to the comments here are inaccessible by now. I'd be happy if I was wrong.

Now it accept zipped folders again...so...I don't know. But we lost the old ones.

[bertllll]

handle_startup_and_shutdown_integration

This test was renovated for this card, MASQ-Project/MASQ-Node-issues#386, however, usually it passes, this time it didn't. Maybe RC.

3_Build node on windows-latest.txt
...
3_Build node on windows-latest.txt

And another one:
22.6.21
3_Build node on windows-latest.txt

Hmmm...this is growing up fast
24.6.2021
3_Build node on windows-latest.txt
26.6.2021 twice
3_Build node on windows-latest.txt
3_Build node on windows-latest.txt

In MASQ-Project/MASQ-Node-issues#451, I was trying to fix this by adding a piece of logic to the code. It may happen that this error will evaporate then.

Nope, without a relief, the frequency of this failure may even have increased.

3_Build node on windows-latest.txt

27th of September
I tried to prevent this issue more reliably with a modification in fallback - connection manager. Card MASQ-Project/MASQ-Node-issues#305.

4th October
Not fixed yet