Flaky Test: TestHiveHistoryBasedStatsTracking.testHistoryBasedStatsCalculator about presto

[jaystarshot]

Just FYI: We have a similar test which uses is based on the same test case https://github.com/prestodb/presto/blob/master/redis-hbo-provider/src/test/java/com/facebook/presto/statistic/TestHistoryBasedRedisStatisticsTracking.java but this is not flaky.
I think this is because we use a test redis client for this test instead of the inmemory handling done. If needed we can combine these 2 and move to presto-tests

[rschlussel]

I looked into #22204 and #22118 during the hackathon, and had a very difficult time reproducing the issue (managed once out of >30k runs).

my suspicion is actually that it's a very slightly flaky feature rather than a flaky test, though i would expect this to affect redis just as much unless it's run in a different test job that happens to encounter this issue less. Basically, I suspect that sometimes the runtime stats from certain nodes from certain operators don't get reported to the coordinator. I only have the test logs to go on, but you can see in this stack trace in this issue that the output node is using hbo stats with the correct output row count, but the test is testing the fliter row count and here the tablescan and filter nodes are using cbo stats.
In the one time i was able to reproduce the issue locally #22204 (comment), we had cbo stats for the scan, and hbo for the filter and output. the hbo stats were 0 for the filter node, but the output node had correct hbo stats.