Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on two main areas: updating Codecov badges in various Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates Codecov badge URLs and introduces support for negative TTL values in packages/node-cache to align with the original node-cache library's behavior. A critical security vulnerability has been identified where very large negative TTL values can lead to non-positive expiration timestamps, causing cache entries to be incorrectly treated as 'unlimited' and never expiring, thus bypassing intended security and cache management. It is recommended to ensure negative TTLs always result in a minimal positive timestamp (e.g., 1) or update the expiration check logic. Additionally, API documentation should be improved by adding @throws tags to JSDocs for methods that can throw errors, and a minor inconsistency in error handling needs to be addressed.
| expirationTimestamp = this.getExpirationTimestamp( | ||
| typeof ttl === "string" ? Number(ttl) : (ttl as number), | ||
| ); |
There was a problem hiding this comment.
The PR introduces support for negative TTL values, which are intended to make cache entries expire immediately. However, the implementation calculates the expiration timestamp by adding the negative TTL to the current time. If the negative TTL is large enough (e.g., less than -54 years), the resulting timestamp becomes zero or negative. Since the cache's expiration logic (in get and checkData) only triggers if the TTL is greater than zero, these entries will be treated as "unlimited" and never expire. This bypasses the intended immediate expiration and can lead to unexpected persistence of data or memory exhaustion if TTLs are influenced by external input.
expirationTimestamp = Math.max(1, this.getExpirationTimestamp(typeof ttl === "string" ? Number(ttl) : (ttl as number)));| result.ttl = this.getExpirationTimestamp( | ||
| typeof ttl === "string" ? Number(ttl) : (ttl as number), | ||
| ); |
There was a problem hiding this comment.
Similar to the set method, the ttl method calculates the expiration timestamp for negative TTLs by adding the negative value to the current time. If the resulting timestamp is zero or negative, the entry will be treated as "unlimited" (never expiring) because the expiration check logic only triggers for TTL values greater than zero. This breaks the intended behavior of immediate expiration for negative TTLs.
result.ttl = Math.max(1, this.getExpirationTimestamp(typeof ttl === "string" ? Number(ttl) : (ttl as number)));| * @returns {boolean} true on success | ||
| */ |
There was a problem hiding this comment.
The JSDoc for the set method is very detailed, which is great. However, it doesn't mention that the method can throw an error. To improve the API documentation, it's good practice to document potential exceptions using the @throws tag.
* @returns {boolean} true on success
* @throws {Error} If the key or TTL is of an invalid type, or if the cache is full (`maxKeys` is reached).
*/| * @returns {boolean} true on success | ||
| */ |
There was a problem hiding this comment.
Similar to the set method, mset can throw errors (e.g., if the input is not an array, or if an underlying set call fails). It would be helpful to document these potential exceptions in the JSDoc for better API clarity.
* @returns {boolean} true on success
* @throws {Error} If the `data` argument is not an array, or if any underlying `set` operation fails.
*/| * @param {number | string} [ttl] TTL in seconds. 0 = unlimited, negative = expires immediately, string = shorthand format | ||
| * @returns {boolean} true if the key has been found and changed. Otherwise returns false. | ||
| */ |
There was a problem hiding this comment.
For consistency with the set method, the ttl method should also validate the ttl argument's type and throw an error if it's invalid. This behavior should then be documented with a @throws tag in the JSDoc.
* @param {number | string} [ttl] TTL in seconds. 0 = unlimited, negative = expires immediately, string = shorthand format
* @returns {boolean} true if the key has been found and changed. Otherwise returns false.
* @throws {Error} If the `ttl` is of an invalid type.
*/![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d685dc590d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (this.isNegativeTtl(ttl)) { | ||
| // Negative TTL: store with a past timestamp so it expires immediately on next access | ||
| expirationTimestamp = this.getExpirationTimestamp( | ||
| typeof ttl === "string" ? Number(ttl) : (ttl as number), | ||
| ); |
There was a problem hiding this comment.
In set(), negative TTLs are passed directly to getExpirationTimestamp(), which can yield ttl <= 0 for inputs like Number.NEGATIVE_INFINITY (or very large-magnitude negative numbers). Because get() and checkData() only expire entries when ttl > 0, those keys become effectively non-expiring instead of "immediately expired" as documented, so stale entries can persist indefinitely; the same pattern is mirrored in ttl().
Useful? React with 👍 / 👎.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1592 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 26
Lines 2473 2473
Branches 558 558
=========================================
Hits 2473 2473 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
1 participant
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
mono - fix: updating codecov badge