It appears that tablet_history_gc-itest is flaky due to interleaving of client operations when automatic flush is enabled. The test is particularly susceptible if an async flush is triggered after each operation.
The issue becomes more apparent when there are two updates to the same row in quick succession, and an async flush is triggered after each one. Sometimes the 2nd update is applied first on the server, then overwritten by the 1st update, even though it was applied first to the client session. This concurrency race may manifest randomly in response to thread and network timing latencies.