fix(daily-cache): surgical tz-migration de-dup for carried days (#770) - #906
Open
ozymandiashh wants to merge 1 commit into
Open
fix(daily-cache): surgical tz-migration de-dup for carried days (#770)#906ozymandiashh wants to merge 1 commit into
ozymandiashh wants to merge 1 commit into
Conversation
…gentseal#770) On a tz-change full re-derive, mergeDayEntries carried a baseline slice whenever the fresh day had no data slice for that (date, provider), so a turn that re-bucketed across local midnight left its old day sliceless, got carried there, AND counted again on its new day. This subtracts from each carried baseline slice exactly what the fresh parse still attributes to that (date, provider) under the OLD bucketing (dateKeyInTz): the re-bucketed turns, nothing else. A sources-gone slice has no such content and survives untouched; a fully-explained slice is dropped; residual slices ADD their sessions instead of max-dedup, since the subtraction already removed the placeholder's share.
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
1 participant
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.
Implements the surgical design this issue prescribed, recovered and verified. @iamtoruk this is the branch you green-lit reviewing on the issue thread; verification protocol results below.
What it does
dateKeyInTzre-buckets the fresh parse under the cache's OLD tz; the carry merge then subtracts from each carried baseline slice exactly what the fresh parse still attributes to that (date, provider) under the old bucketing - the re-bucketed midnight turns, nothing else. Sources-gone slices have no such content and survive untouched. Residual slices ADD their sessions instead of max-dedup (the subtraction already removed the placeholder's share; max would clamp 1+1 to 1 and permanently drop a source-gone session).Verification
Synthetic: 9 dedicated cases in
tests/daily-cache-tz-dedup.test.ts(subtraction exactness, sources-gone preservation, full-explanation drop, residual session arithmetic, nested model/category/project slices) plus the full carry-forward suite: 81/81 across the daily-cache suites locally.Real data, the #762 kill-scenario: fresh v16 cache hydrated from this machine's real session corpus (94 days, $14,563.81), tzKey flipped Europe/Bucharest -> America/New_York, full re-derive forced:
Zero days dropped, zero spurious deltas - the exact scenario where #762's coverage floor dropped a genuine day is now lossless. Honest limitation: this machine's corpus is fully file-backed (no carried days), so the carried-slice subtraction itself is exercised by the synthetic suite, not the real-data run; your cache with genuine source-gone days is the stronger final validation.
Note: the suite run stacked #901's test-portability fixes locally (the noon-fixture failure in cli-durable-totals is #901's, not this branch's); whichever merges second rebases clean.