items are not pro-actively pruned out as they age
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript
- Domain
- backend, performance
Research direction
Start by reading the cache implementation and its existing tests to understand how entries are stored, accessed, and evicted. Define how age-based pruning should work for keys that are never accessed, including its scheduling and resource costs. Done means stale entries are removed without clearing live entries and the behavior is covered by tests.
Written by the indexing model from the issue text.
Description
items are not pro-actively pruned out as they age
I'm thinking about memory leaks in this case if LRU is used on a server and cache key is something time based (e.g "today"). In this scenario old keys (when today has moved to the next day) will never be accessed (neither set or get), so never pruned. How would you solve it?
I see one simple/stupid solution to do like setInterval that does cache.clear() once in a while. But that would clear all items, not only stale.
- Dominant language
- JavaScript
- Stars
- 177
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
[Block] Latest Posts [Type] Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
sugarlabs/musicblocks#8847 ·