Is there an existing issue for this?
Describe the bug
The CollectionTsCache is a LRU cache capped at DEFAULT_CAPACITY=4096. Once the cap is exceeded. After eviction CollectionTsCache::get returs 0 and construct_guarantee_ts (ts_utils.py) falls back to guarantee_ts = 1, the weakest bound, so a SESSION-consistency read of a collection that was written but then evicted silently degrades to eventually-consistent with no error or signal. This is reachable under many-collection multi-tenant load.
Expected Behavior
No response
Steps/Code To Reproduce behavior
Environment details
- Hardware/Softward conditions (OS, CPU, GPU, Memory):
- Method of installation (Docker, or from source):
- Milvus version (v0.3.1, or v0.4.0):
- Milvus configuration (Settings you made in `server_config.yaml`):
Anything else?
No response
Is there an existing issue for this?
Describe the bug
The CollectionTsCache is a LRU cache capped at DEFAULT_CAPACITY=4096. Once the cap is exceeded. After eviction CollectionTsCache::get returs 0 and construct_guarantee_ts (ts_utils.py) falls back to guarantee_ts = 1, the weakest bound, so a SESSION-consistency read of a collection that was written but then evicted silently degrades to eventually-consistent with no error or signal. This is reachable under many-collection multi-tenant load.
Expected Behavior
No response
Steps/Code To Reproduce behavior
Environment details
Anything else?
No response