Conversation
`get_next_auto_restatement_interval` computed the start as `end - N * interval_unit.milliseconds`, and a MONTH interval unit is 28 days long. For monthly models the start drifted about 2.4 days per month, so from 13 intervals on the cron floor landed a month too late and the oldest month was never restated (13 restated 12, 24 restated 23). Step back N intervals with the interval unit's cron instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: breken-ai <312387581+breken-ai@users.noreply.github.com>
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.
Description
auto_restatement_intervalsshould restate the last N intervals.Snapshot.get_next_auto_restatement_intervalcomputes the start asend - N * interval_unit.milliseconds. For a monthly model,IntervalUnit.MONTH.millisecondsis 28 days, so the start moves about 2.4 days later for every month counted back.apply_auto_restatementsthen floors that start to the beginning of its month.For a monthly model with intervals through June 2024, restated on 2024-07-02:
auto_restatement_intervalsThis matters when the setting is used to pick up late corrections, for example "restate the last 24 months". The oldest month is silently left out on every run and its stale data is never refreshed.
The fix steps back N intervals with the interval unit's cron, the same way
expand_rangeandinclusive_exclusivedo. For fixed-length units (day, hour, minutes) the result is the same as before, and for months and years it is calendar-exact.Test Plan
test_apply_auto_restatements_monthly, parametrized for 1, 12, 13 and 24 intervals. It checks both the pending restatement interval and the intervals left on the snapshot. Onmain(263723f) the 13 and 24 cases fail (the restatement starts on 2023-07-01 and 2022-08-01) and 1 and 12 pass. All four pass with the fix.test_get_next_auto_restatement_intervalandtest_apply_auto_restatements(hourly with 24 intervals, daily with 2 and 5) still pass.pytest tests/core/test_snapshot.py tests/core/test_scheduler.py: 162 passed.pytest tests/core/integration -k restatement: 24 passed.ruff check,ruff format --checkandmypy sqlmesh/core/snapshot/definition.pyare clean for the changed files.Checklist
make styleand fixed any issuesmake fast-test)git commit -s) per the DCOI ran ruff and mypy directly rather than the full pre-commit suite. I ran the snapshot, scheduler and restatement integration tests rather than the full
make fast-test.This fix was found and written with AI assistance (Claude).