Version 0.12.16
Fixed
- Fixed a bug where cache eviction could stall permanently when the cache was configured with the non-default LRU eviction policy (
EvictionPolicy::lru()) by a race between insert and remove operations on the same key (#592 by @kim-jhyeon, reported in #590):- This bug was introduced in v0.12.0 and affected
sync::Cache,sync::SegmentedCacheandfuture::Cache. - A race between applying a write recording for an entry and concurrently removing that entry from the internal concurrent hash table could leave an orphaned node at the front of the LRU queue. Once present, no entry was ever evicted again and the cache grew unboundedly past
max_capacity. - The same race also affected the default TinyLFU eviction policy, but with a milder symptom: each occurrence permanently leaked one phantom entry slot, causing
entry_countandweighted_sizeto over-report and the usable capacity to shrink by one entry per occurrence. Fixed by the same change.
- This bug was introduced in v0.12.0 and affected
Changed
- Worked around a ThreadSanitizer false positive (#602):
- Replaced the standalone
fence(Acquire)in the internalMiniArc's drop path with anAcquireload of the reference count, so that downstream projects can now run ThreadSanitizer on code using Moka without hitting this false positive. std::sync::Archas a similar workaround.
- Replaced the standalone
- Raised the minimum version of the
crossbeam-epochcrate fromv0.9.18tov0.9.20to avoid the following advisory (#603):- [RUSTSEC-2026-0204] crossbeam-epoch: invalid pointer dereference in
fmt::PointerforAtomicandShared - Moka is not affected by this advisory because it never formats these pointer types. However, raising the minimum version prevents downstream lockfiles from resolving to an affected
crossbeam-epochversion via Moka.
- [RUSTSEC-2026-0204] crossbeam-epoch: invalid pointer dereference in