fix(dashboard): getTimeRange returns full data extent under an active TimeWindow#284
Merged
Merged
Conversation
… TimeWindow FastSenseWidget.getTimeRange() reports the cached data extent for the navigator/preview, which must be independent of the per-widget TimeWindow_. But updateTimeRangeCache()'s fast path trusted the already-pulled x as the full extent — and when a TimeWindow_ is set, callers pass the WINDOWED pull (pullData_ -> Tag.getXYRange). That set CachedXMax to the window end, so getTimeRange() returned [fullStart, windowEnd] (CachedXMin is sticky, which is why only the max was wrong). Fix: only take the passed-x fast path when TimeWindow_ is empty; with a window active, fall through to the Tag's own (full) getTimeRange()/getXY(). No extra work in the common windowless case; one O(1) Tag.getTimeRange() when windowed. Regression guard: existing tests/test_dashboard_time_window.m testPreviewStillFull (was failing on main). Verified fresh-process: repro fixed (tMax full extent), test_dashboard_time_window 8/8, and 95/96 across FastSenseWidget/preview/dashboard suites (the 1 is the pre-existing headless TestDashboardEngine/testTimerContinuesAfterError, unrelated). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
HanSur94
added a commit
that referenced
this pull request
Jun 29, 2026
…nge/TimeWindow fix so CI picks up the Dashboard fix
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.
Problem
FastSenseWidget.getTimeRange()returns the cached data extent used by the navigator / preview, which is documented to be independent of the per-widgetTimeWindow_. It was instead returning the window end astMax.TestDashboardTimeWindow/testPreviewStillFullcatches this and is currently failing onmain(e.g. scheduled run,getTimeRange tMax=739256 should reflect full extent end ~739261— 739256 is exactly the window endt0+4).Root cause
updateTimeRangeCache()'s fast path (added in 260610-ov3) trusts the already-pulledxas the full extent to avoid a secondgetXY(). But when aTimeWindow_is set, callers pass the windowed pull (pullData_→Tag.getXYRange), soCachedXMaxbecame the window end. (CachedXMinis sticky, so only the max was wrong.)Fix
Only take the passed-
xfast path whenTimeWindow_is empty. With a window active, fall through to the Tag's own fullgetTimeRange()/getXY(). One line + comment; no extra work in the common windowless case, one O(1)Tag.getTimeRange()when windowed.Verification (fresh MATLAB process,
restoredefaultpath)tMax = t0+9).tests/test_dashboard_time_window.m: 8/8 (the previously-failingtestPreviewStillFullpasses).TestDashboardEngine/testTimerContinuesAfterError(unrelated; "Filtered by assumption" in CI).Found while triaging CI on #214; kept as a separate, independent fix.
🤖 Generated with Claude Code