fix: remove lru-cache and reduce ttls to avoid memory leaks

[vinikjkkj]

No description provided.

[whiskeysockets-bot]

Thanks for opening this pull request and contributing to the project!

The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch.

In the meantime, anyone in the community is encouraged to test this pull request and provide feedback.

✅ How to confirm it works

If you’ve tested this PR, please comment below with:

Tested and working ✅

This helps us speed up the review and merge process.

📦 To test this PR locally:

# NPM
npm install @whiskeysockets/baileys@WhiskeySockets/Baileys#improve-caches

# Yarn (v2+)
yarn add @whiskeysockets/baileys@WhiskeySockets/Baileys#improve-caches

# PNPM
pnpm add @whiskeysockets/baileys@WhiskeySockets/Baileys#improve-caches

If you encounter any issues or have feedback, feel free to comment as well.

[jlucaso1]

nice catch

[gusquadri]

I dont think make sense to remove the LRU cache, it already had TTL and the fact node cache doesnt support update ttl on get will make it try to migrate/store again wrongly even when its being used constantly

[vinikjkkj]

I dont think make sense to remove the LRU cache, it already had TTL and the fact node cache doesnt support update ttl on get will make it try to migrate/store again wrongly even when its being used constantly

On big projects the memory can grow too fast with 7 days TTL, we can update manually the TTL (re-adding the key) what do you think?

[gusquadri]

I dont think make sense to remove the LRU cache, it already had TTL and the fact node cache doesnt support update ttl on get will make it try to migrate/store again wrongly even when its being used constantly

On big projects the memory can grow too fast with 7 days TTL, we can update manually the TTL (re-adding the key) what do you think?

I think it would be a good approach too, or just decrease the TTL

[purpshell]

Let's not keep on jumping back and forth in dependencies.

Is there a fundamental issue with lru-cache itself? Why node-cache?

[wis-dev]

Let's not keep on jumping back and forth in dependencies.

Is there a fundamental issue with lru-cache itself? Why node-cache?

I think lru-cache is the best option. If you have memory leaks read Storage Bounds Safety

[github-actions]

This PR is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days