Repository navigation
recalculate size when set() is given the same value again - #416
Open
OsamaAnsar wants to merge 1 commit into
Open
OsamaAnsar wants to merge 1 commit into
OsamaAnsar wants to merge 1 commit into
Conversation
If set(k, v) was called with the value already stored at k, the entry's size was not updated, even if v had been mutated since (so that sizeCalculation now returns something different), or a different `size` option was given. calculatedSize then drifted away from the real total, and maxSize could be exceeded without anything being evicted. The update path now removes and re-adds the item size whether or not the value is the same one. This also reports entrySize and totalCalculatedSize in the status of such a set().
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
set(k, v)with the value already stored atkskipped the size update, becauseremoveItemSize/addItemSizeonly run insideif (v !== oldVal). So after mutating an object and setting it again (or passing a differentsizefor the same value), the stored size stayed stale.calculatedSizedrifted from the real total andmaxSizecould be exceeded with nothing evicted. ThemaxEntrySizecheck already uses the new size, so this was also inconsistent.Before (
sizeCalculation: v => v.length,maxSize: 100,agrown from length 3 to 50 and set again, thenbof length 60 added):After:
The fix calls
removeItemSize/addItemSizein the same-value branch too. Dispose,onInsertand TTL handling for that path are untouched. One visible side effect: thestatusof such aset()now hasentrySizeandtotalCalculatedSize, as it already does for a replacingset(). That changes one existing entry intap-snapshots/test/tracing.ts.test.cjs, plus new entries for the new tests.Tests are in
test/size-calculation.ts: mutated object withsizeCalculation(growing, shrinking, eviction order), explicitsizeon the same value (eviction of another entry, and removal when it exceedsmaxSize), and no dispose on same-valueset(). With only the source change reverted, 12 assertions in those 3 tests fail; with the fix they pass.Checked on Node v24.19.0 on Windows: full
tap -t0run (coverage enforcement left on) passes with 0 failures,oxlint src testreports 0 warnings and 0 errors, andprettier --checkis clean. I did not run Linux or macOS, other Node versions, or a browser; the change is plain arithmetic on the existing size bookkeeping. (On this machine I rantapwith a small preload that falls back to junctions forsymlink, and installed@tapjs/clockwith--no-save, see #413. Neither is part of this PR.)