Problem

The cppsuite hs_cleanup test (task cppsuite-hs-cleanup-stress-perf, variant ubuntu2004-perf-tests) saves the metric cache_hs_insert to the perf results. The reported value is always 0, even though the same run did many history store inserts.

Evidence

• SPS time series for cache_hs_insert is 0 on every run from 2023-09-22 (order 9451) to 2026-11-09 (order 13172). The stable region has mean 0 and std 0, so it never changed.
• In 6 patch runs on develop 4ca01f76c1 (WT-19032 A/B test), the in-run stat file WiredTigerStat.* has cache: history store table insert calls at 356k to 371k at the end of each run. The reported cache_hs_insert is 0 for all 6.
• In the same runs, cc_pages_removed from the same code path matches the stat file exactly (170291 in both for one run). So the stats cursor read works for that metric, and only cache_hs_insert is wrong.

Code path

• test/cppsuite/src/component/metrics_monitor.cpp: get_stat_field() maps cache_hs_insert to WT_STAT_CONN_CACHE_HS_INSERT. finish() reads it with statistics::get_value() through the statistics: cursor.
• Config: test/cppsuite/configs/hs_cleanup_stress.txt (cache_hs_insert=(save=true)).

Not yet known

The cause. I did not find out why the value is 0. Things to check: whether the stat id used by the cursor lookup matches the history store insert stat, whether the history store inserts are counted on a different handle or are cleared before finish(), and whether the cursor is reset or the stats are cleared before the read.

Impact

The metric gives no signal and cannot detect a real change in history store activity. This hides whether a change point on stat_db_size comes from history store behaviour. Found while triaging WT-19032.

Done when

• The cause is found.
• cache_hs_insert reports a non-zero value that matches the stat file in hs_cleanup, or the metric is removed if it cannot be fixed.