Repository navigation
fix: align the backfill start to the time bucket on reruns #1078
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
20d0342
fix: align the backfill start to the time bucket on reruns
joostboon 3d8a7d9
refactor: align the backfill start where it is defined
joostboon 6f31f6c
test: keep the rerun backfill start mid-bucket and cover multi-day bu…
joostboon af194fb
Merge master into fix/align-backfill-to-bucket
joostboon abf38c7
Merge branch 'master' into fix/align-backfill-to-bucket
joostboon aa05c85
test: upload in the latest Monday's week so Sunday-start warehouses p…
1ead7de
Merge branch 'master' into fix/align-backfill-to-bucket
joostboon File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick question about installs that already ran with the old behavior. They'll have weekly or multi-day rows in
data_monitoring_metricswith shiftedbucket_startvalues. After this change the reruns will write aligned buckets next to them. Do those old rows get replaced or ignored when the anomaly scores are computed, or could they overlap with the new buckets in the training window? If it's already handled, ignore me. If not, might be worth a note in the PR or a cleanup path.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, for timestamped tests the anomaly query only reads history whose bucket_start/bucket_end exactly match a bucket in the current run’s grid (get_anomaly_scores_query.sql), so the shifted rows are ignored. The incremental check in get_buckets_configuration.sql matches on the same exact start/end, so after the upgrade the aligned buckets count as missing and the first run backfills them from the start of days_back. Later runs find them and skip them.
Two side effects, neither needing code: the first run after upgrading recomputes the full days_back window for weekly and multi-day tests on sources and incremental models, so it’s heavier once, and the old shifted rows stay in data_monitoring_metrics (unused) until normal cleanup removes them.
On the multi-day grid moving with
days_backand the run date: it’s known behavior and only affects count > 1 day/week/month buckets. Each run builds and scores on its own grid, so results stay correct. The cost is that the incremental cache mostly misses for those tests and rows from older grids pile up in data_monitoring_metrics. Since it’s a cost issue on an uncommon config, I’m not planning to change it unless we see someone using multi-day buckets at scale. what do you think? happy to open a ticket if you think it's needed