Closed ondrej-fabry closed 1 year ago
Another random failure popped up, the failing test is in this case TestTraceClear
:
=== Failed
=== FAIL: core TestTraceClear (0.00s)
trace_test.go:263:
Expected
<[]*api.Record | len:3, cap:3>: [
{
Message: <*interfaces.CreateLoopback | 0xc0020b470a>{
MacAddress: [0, 0, 0, 0, 0, 0],
},
Timestamp: 2023-02-23T09:45:44.068699612Z,
IsReceived: false,
ChannelID: 1,
},
{
Message: <*interfaces.CreateLoopbackReply | 0xc0020b4758>{Retval: 0, SwIfIndex: 0},
Timestamp: 2023-02-23T09:45:44.068726512Z,
IsReceived: true,
ChannelID: 1,
},
{
Message: <*memif.MemifCreateReply | 0xc0020b4788>{Retval: 0, SwIfIndex: 0},
Timestamp: 2023-02-23T09:45:44.068879412Z,
IsReceived: true,
ChannelID: 1,
},
]
to have length 4
DONE 90 tests, 1 skipped, 1 failure in 48.670s
Error: Process completed with exit code 1.
@ondrej-fabry the problem here is that trace records are processed from several goroutines, and if any of them stumble and the GetRecord
is called fast enough, some records might not make it to the list. The test then fails, because it expects exact numbers.
This could happen to any trace test. It's enough to run it like 100k times in a loop and it eventually fails.
I reimplemented the trace here #116 to mitigate the race and fasten up the API tracing process. If you don't like the change, it can be also fixed with a single 1ms sleep line.
The test case
TestTraceEnabled
seems to be failing at random occurrences.Here is a log output from recent failure that occurred in CI Workflow: