Stale cache results during read repair with consistency level operations

In Apache Cassandra, read repair is documented to trigger when replicas return inconsistent data during a read, but the interaction between this repair path and the row cache or key cache can leave stale entries visible to clients. The precise question is under what conditions a cache invalidation is guaranteed to propagate to all replicas after a read repair, and whether a subsequent read at the same consistency level should be expected to return the repaired value or a stale cached result.

Relevant constraints include version-specific behavior between Cassandra 3.x and 4.x, the configured row_cache_size_in_mb and key_cache_size_in_mb, and the compaction strategy in use, since LeveledCompactionStrategy can affect how quickly inconsistencies are resolved. Network partition duration and the timing of cache invalidation relative to the repair operation further complicate the expected outcome. Because these variables interact and behavior may differ across releases, it is unclear which configuration combinations make stale reads a transient symptom versus a persistent failure condition.

Does a read repair operation invalidate stale cache entries synchronously on all replicas, or only on the coordinator? How do row_cache_size_in_mb and key_cache_size_in_mb change the observable window in which a stale read can occur after repair? Is there a documented consistency level or compaction strategy combination that eliminates stale cache results during read repair, or is the behavior always version-dependent?