ASAN and long-e2e-debug runs are are unstable after test_historical_query_range.
This submits range queries which can last > 4s, and which when WORKER_THREADS=0 cause the main loop to halt.
This then causes an election, but not before a client is created to the primary to validate receipts, which then gets punted due to SessionConsistencyLost.
ASAN is slow due to ASAN, long-e2e-debug is slow due to the GLIBCXX_DEBUG.
Some exploration implies that this might be due to building the initial index for the historical queries, but has been inconclusive and I don't have a reliable repro.
The likely solution is to just test with WORKER_THREADS > 0, or to make the polling loop do retries if there is a SessionConsistencyLost error.
I'm hesitant to do either of those until we know why this is slow.
ASAN and long-e2e-debug runs are are unstable after test_historical_query_range.
This submits range queries which can last > 4s, and which when
WORKER_THREADS=0cause the main loop to halt.This then causes an election, but not before a client is created to the primary to validate receipts, which then gets punted due to SessionConsistencyLost.
ASAN is slow due to ASAN, long-e2e-debug is slow due to the GLIBCXX_DEBUG.
Some exploration implies that this might be due to building the initial index for the historical queries, but has been inconclusive and I don't have a reliable repro.
The likely solution is to just test with
WORKER_THREADS> 0, or to make the polling loop do retries if there is aSessionConsistencyLosterror.I'm hesitant to do either of those until we know why this is slow.