fix(frontend): UTC day boundaries so dashboard today matches everywhere - #2931
Open
riderx wants to merge 8 commits into
Open
fix(frontend): UTC day boundaries so dashboard today matches everywhere#2931riderx wants to merge 8 commits into
riderx wants to merge 8 commits into
Conversation
Dashboard charts derived "today" from browser-local midnight then converted with toISOString(), so Europe (east of UTC) requested yesterday while Brazil kept today. Align all dashboard date ranges and API params with UTC days to match backend daily_* buckets. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Contributor
📝 WalkthroughWalkthroughThe PR centralizes UTC date handling and dashboard chart behavior. It adds shared billing-cycle, series transformation, Chart.js registration, color, today-line, filtering, and loading-delay utilities. ChangesUTC date and range foundation
Shared chart contracts and services
Dashboard data and loading flows
Dashboard chart integrations
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant DashboardComponent
participant BillingCycleComposable
participant DailySeriesService
participant ChartTodayLine
DashboardComponent->>BillingCycleComposable: resolve UTC cycle and today limits
DashboardComponent->>DailySeriesService: transform daily series
DashboardComponent->>ChartTodayLine: create today-line options
ChartTodayLine-->>DashboardComponent: return chart configuration
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Comment |
Contributor
Merging this PR will not alter performance
Comparing 
Footnotes
|
Remove unused normalizeToStartOfDay and share billing-period filter plus chart today/transform helpers to drop new-code duplication. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Move billing-cycle chart helpers into useOrgBillingCycleChart and reuse computeLastDayEvolution / ensureMinDelay so new-code duplication stays under the Sonar quality gate. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Extract createTodayLineOptions and hue helpers so Sonar no longer counts duplicated new-code blocks across dashboard charts. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Register dashboard charts once and use useCurrentOrgBillingCycleChart so file preambles no longer share long duplicated new-code blocks. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Extract dailyChartBaseProps so dashboard charts no longer share long identical defineProps blocks counted as new duplication. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Share useDashboardDailyChartCycle and diversify chart file preambles so identical new-code blocks stay under the duplication threshold. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
riderx
marked this pull request as ready for review
August 7, 2026 21:21
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_e12b6610-73ad-498d-abfa-a036f67453e7) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/dashboard/BundleUploadsChart.vue`:
- Around line 16-17: Replace the relative imports in
src/components/dashboard/BundleUploadsChart.vue lines 16-17 and
src/components/dashboard/DeploymentStatsChart.vue lines 16-17 with
~/components/dashboard/... alias paths for createChartLegendItems and
ChartLegend. Replace the relative chartTooltip import in
src/components/dashboard/UpdateStatsChart.vue line 17 with
~/services/chartTooltip.
In `@src/components/dashboard/DeploymentStatsCard.vue`:
- Around line 145-146: Update the DeploymentStatsCard date-range query to
compute the next UTC day after last30DaysEnd, format it with formatUtcDateParam,
and filter deployed_at with an exclusive .lt() bound instead of .lte(). Add a
boundary test covering a deployment later on the current UTC day.
In `@src/services/chartTooltip.ts`:
- Around line 64-77: Update the log-navigation handler in UpdateStatsChart.vue
to derive both start and end query bounds from the selected UTC calendar date
using Date.UTC, preserving the day represented by clickContext.date across local
time zones. Remove the unused dayjs import, and add a non-UTC timezone test
covering the generated start and end parameters.
In `@src/services/dashboardChartRegister.ts`:
- Around line 1-30: Update registerDashboardCharts to import the Chart.js Legend
component and include Legend in the Chart.register call, ensuring
UpdateStatsChart’s enabled plugins.legend renders on direct page loads.
In `@src/services/date.ts`:
- Around line 186-190: Update getChartDateRange to parse date-only billingStart
and billingEnd values with a dedicated UTC range-boundary parser before
normalizeToUtcStartOfDay, while preserving parseDatePreservingUtc for localized
display paths. Add a regression test covering getChartDateRange(true,
'2026-08-07', ...) in a positive-offset timezone and verify the UTC date remains
August 7.
- Around line 159-165: Replace the nested ternary in formatUtcDateParam with an
if-based branch that selects the DATE_ONLY_RE UTC parsing path versus the
regular string parsing path, while preserving the existing Date handling,
invalid-date empty-string return, and ISO date formatting.
In `@src/stores/organization.ts`:
- Around line 360-363: Normalize the UTC start-of-day once before calculating
the billing range, then derive both last30DaysEnd and last30DaysStart from that
single anchor. Preserve the existing offsets so the request consistently covers
the intended 30-day window.
In `@src/utils/chartOptimizations.ts`:
- Around line 27-49: Update filterDailySeriesToBillingPeriod to normalize
billingStart to the UTC start of its day, derive the active billing-cycle start
using calendar-month arithmetic, and calculate currentBillingDay as the UTC
elapsed-day difference from that boundary plus one. Use the normalized
billingStart for date comparisons and billingIndex calculations so cycles
spanning months of different lengths retain every day.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 047a23cf-49a1-4fac-9b4f-33925a2164b4
📒 Files selected for processing (26)
src/components/dashboard/BundleUploadsCard.vuesrc/components/dashboard/BundleUploadsChart.vuesrc/components/dashboard/DeploymentStatsCard.vuesrc/components/dashboard/DeploymentStatsChart.vuesrc/components/dashboard/DevicesStats.vuesrc/components/dashboard/LineChartStats.vuesrc/components/dashboard/UpdateStatsCard.vuesrc/components/dashboard/UpdateStatsChart.vuesrc/components/dashboard/Usage.vuesrc/composables/useBuildChartConfig.tssrc/composables/useOrgBillingCycleChart.tssrc/services/buildCharts.tssrc/services/chartDataService.tssrc/services/chartTodayLine.tssrc/services/chartTooltip.tssrc/services/conversion.tssrc/services/dailyChartProps.tssrc/services/dashboardChartRegister.tssrc/services/date.tssrc/services/supabase.tssrc/stores/main.tssrc/stores/organization.tssrc/utils/chartOptimizations.tssrc/utils/minDelay.tstests/dashboard-date-range.unit.test.tstests/date.unit.test.ts
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
Cap-go/capacitor-updater(manual)
Comment on lines
16
to
17
| import { createChartLegendItems } from './chartLegend' | ||
| import ChartLegend from './ChartLegend.vue' |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Use the frontend alias for all new src/ imports.
src/components/dashboard/BundleUploadsChart.vue#L16-L17: Replace./chartLegendand./ChartLegend.vuewith their~/components/dashboard/...paths.src/components/dashboard/DeploymentStatsChart.vue#L16-L17: Replace./chartLegendand./ChartLegend.vuewith their~/components/dashboard/...paths.src/components/dashboard/UpdateStatsChart.vue#L17-L17: Replace../../services/chartTooltipwith~/services/chartTooltip.
As per coding guidelines, import using the ~/ alias for the src/ directory in frontend code instead of relative paths.
📍 Affects 3 files
src/components/dashboard/BundleUploadsChart.vue#L16-L17(this comment)src/components/dashboard/DeploymentStatsChart.vue#L16-L17src/components/dashboard/UpdateStatsChart.vue#L17-L17
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/dashboard/BundleUploadsChart.vue` around lines 16 - 17,
Replace the relative imports in src/components/dashboard/BundleUploadsChart.vue
lines 16-17 and src/components/dashboard/DeploymentStatsChart.vue lines 16-17
with ~/components/dashboard/... alias paths for createChartLegendItems and
ChartLegend. Replace the relative chartTooltip import in
src/components/dashboard/UpdateStatsChart.vue line 17 with
~/services/chartTooltip.
Source: Coding guidelines
Comment on lines
+27
to
+49
| export function filterDailySeriesToBillingPeriod(fullData: number[], last30DaysStart: Date, billingStart: Date) { | ||
| const currentDate = normalizeToUtcStartOfDay() | ||
|
|
||
| let currentBillingDay: number | ||
| if (billingStart.getUTCDate() === 1) { | ||
| currentBillingDay = currentDate.getUTCDate() | ||
| } | ||
| else { | ||
| const billingStartDay = billingStart.getUTCDate() | ||
| const daysInMonth = new Date(Date.UTC(currentDate.getUTCFullYear(), currentDate.getUTCMonth() + 1, 0)).getUTCDate() | ||
| currentBillingDay = (currentDate.getUTCDate() - billingStartDay + 1 + daysInMonth) % daysInMonth | ||
| if (currentBillingDay === 0) | ||
| currentBillingDay = daysInMonth | ||
| } | ||
|
|
||
| const billingData = Array.from({ length: currentBillingDay }).fill(0) as number[] | ||
| for (let i = 0; i < 30; i++) { | ||
| const dataDate = addUtcDays(last30DaysStart, i) | ||
| if (dataDate >= billingStart && dataDate <= currentDate) { | ||
| const billingIndex = Math.floor((dataDate.getTime() - billingStart.getTime()) / (1000 * 60 * 60 * 24)) | ||
| if (billingIndex >= 0 && billingIndex < currentBillingDay) | ||
| billingData[billingIndex] = fullData[i] | ||
| } |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Calculate the billing-day count from the active cycle boundary.
The day-of-month formula fails when the cycle crosses months with different lengths. For a cycle starting March 30 and a current date of April 1, Lines 36-39 calculate 2. The cycle contains three UTC days. Line 47 then drops the April 1 value at billing index 2.
Derive the active billing-cycle start with calendar-month arithmetic. Then calculate currentBillingDay from the UTC elapsed-day difference plus one. Normalize billingStart in this helper before comparisons.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/utils/chartOptimizations.ts` around lines 27 - 49, Update
filterDailySeriesToBillingPeriod to normalize billingStart to the UTC start of
its day, derive the active billing-cycle start using calendar-month arithmetic,
and calculate currentBillingDay as the UTC elapsed-day difference from that
boundary plus one. Use the normalized billingStart for date comparisons and
billingIndex calculations so cycles spanning months of different lengths retain
every day.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
6 issues found across 26 files
Confidence score: 2/5
src/components/dashboard/LineChartStats.vuestill mixes UTC cycle/today indexing with localgetCurrentDayMonth()inaccumulateDataand the per-app reducer, so day cutoffs can drift by browser timezone and show the wrong cumulative point/day boundary; align all day-bucketing and "today" logic to one timezone basis (preferably UTC) end-to-end.src/services/chartTooltip.tspasses a UTC-midnight date intoclickContext, butUpdateStatsChartderives local-day bounds, so clicking a day can open logs for a different date for some users; use the same normalized day reference for tooltip click payload and log-query range construction.src/components/dashboard/LineChartStats.vueappears to extend expired billing ranges to the current day, producing empty trailing labels and marking a synthetic final point as "today"; cap chart range/today-marker logic atsubscription_endfor expired periods.src/services/buildCharts.tsand dedup changes are lower risk but worth cleanup: removing end-of-day handling changescreated_atupper-bound semantics to "now," andsrc/utils/minDelay.tsis not yet adopted by the duplicated callers; restore explicit end-bound behavior if intended and migrate callers to the shared helper to avoid drift.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/services/chartTooltip.ts">
<violation number="1" location="src/services/chartTooltip.ts:64">
P2: Clicking an update-chart day can open logs for a different day depending on the viewer's timezone. The UTC-midnight `Date` introduced here is passed through `clickContext`, but `UpdateStatsChart` still derives local-day bounds; the click path should preserve the UTC calendar day when constructing the log query (or pass a calendar-day-safe local `Date` separately from the UTC tooltip date).</violation>
</file>
<file name="src/utils/minDelay.ts">
<violation number="1" location="src/utils/minDelay.ts:2">
P3: This helper duplicates the identical `elapsed < 300 → setTimeout` spinner-delay block already inlined in useBuildCardStats.ts, Usage.vue, and UpdateStatsCard.vue. Since the PR's goal is deduplication, migrate those three inline spots to call `ensureMinDelay(startTime)`; otherwise refreshData/usage/update paths keep two parallel implementations of the same logic.</violation>
</file>
<file name="src/components/dashboard/LineChartStats.vue">
<violation number="1" location="src/components/dashboard/LineChartStats.vue:48">
P1: Cumulative usage can still shift its cutoff by the browser timezone: this line switches the chart cycle/today index to UTC, but `accumulateData` and the per-app reducer continue using local `getCurrentDayMonth()`. Reusing the composable’s UTC `transformDailySeries` for both total and per-app data would keep the cumulative today bucket aligned with the UTC marker.</violation>
<violation number="2" location="src/components/dashboard/LineChartStats.vue:48">
P2: Expired billing periods now render empty labels through the current day and mark that synthetic final day as “today” instead of stopping at `subscription_end`. Keeping a past subscription end for the billing range (and using today only when no end exists) would preserve the existing billing-period contract.</violation>
</file>
<file name="src/composables/useBuildChartConfig.ts">
<violation number="1" location="src/composables/useBuildChartConfig.ts:7">
P3: The new `createTodayLineOptions` helper centralizes the today-line styling, but `useBuildChartConfig` still returns the same inline today-line config with the identical hardcoded colors rather than delegating to the helper. This leaves two copies of the today-line look in the codebase, defeating the PR's dedup goal: future styling changes have to be updated in both places. Consider calling `createTodayLineOptions` here too (it already replicates the same `useBillingPeriod`/index guard).</violation>
</file>
<file name="src/services/buildCharts.ts">
<violation number="1" location="src/services/buildCharts.ts:62">
P3: The build chart's created_at upper bound changed behavior: the old `endOfToday.setHours(23,59,59,999)` (end of local day) was removed, so `endISO` is now the instant the window is built (`new Date()`), while `todayStart` moved to UTC midnight. This makes `endISO` time-of-fetch dependent and no longer 'end of today' as the `BuildChartWindow.endISO` comment documents, and it isn't aligned with the UTC day boundary that `todayStart` now uses. Consider restoring the intent by normalizing to the UTC end of day (e.g. `endOfToday.setUTCHours(23,59,59,999)`) or updating the comment/name to reflect that `endISO` is now 'fetch time' rather than end of today.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| }) | ||
| return mapping | ||
| }) | ||
| const { cycleStart, cycleEnd, todayLimit } = useDashboardDailyChartCycle(() => props.useBillingPeriod) |
There was a problem hiding this comment.
P1: Cumulative usage can still shift its cutoff by the browser timezone: this line switches the chart cycle/today index to UTC, but accumulateData and the per-app reducer continue using local getCurrentDayMonth(). Reusing the composable’s UTC transformDailySeries for both total and per-app data would keep the cumulative today bucket aligned with the UTC marker.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/components/dashboard/LineChartStats.vue, line 48:
<comment>Cumulative usage can still shift its cutoff by the browser timezone: this line switches the chart cycle/today index to UTC, but `accumulateData` and the per-app reducer continue using local `getCurrentDayMonth()`. Reusing the composable’s UTC `transformDailySeries` for both total and per-app data would keep the cumulative today bucket aligned with the UTC marker.</comment>
<file context>
@@ -49,48 +39,29 @@ const props = defineProps({
- })
- return mapping
-})
+const { cycleStart, cycleEnd, todayLimit } = useDashboardDailyChartCycle(() => props.useBillingPeriod)
-// Click handler for tooltip items - navigates to app detail page
</file context>
| @@ -0,0 +1,6 @@ | |||
| /** Ensure at least `minMs` elapsed since `startTime` before continuing (spinner UX). */ | |||
| export async function ensureMinDelay(startTime: number, minMs = 300) { | |||
There was a problem hiding this comment.
P3: This helper duplicates the identical elapsed < 300 → setTimeout spinner-delay block already inlined in useBuildCardStats.ts, Usage.vue, and UpdateStatsCard.vue. Since the PR's goal is deduplication, migrate those three inline spots to call ensureMinDelay(startTime); otherwise refreshData/usage/update paths keep two parallel implementations of the same logic.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/utils/minDelay.ts, line 2:
<comment>This helper duplicates the identical `elapsed < 300 → setTimeout` spinner-delay block already inlined in useBuildCardStats.ts, Usage.vue, and UpdateStatsCard.vue. Since the PR's goal is deduplication, migrate those three inline spots to call `ensureMinDelay(startTime)`; otherwise refreshData/usage/update paths keep two parallel implementations of the same logic.</comment>
<file context>
@@ -0,0 +1,6 @@
+/** Ensure at least `minMs` elapsed since `startTime` before continuing (spinner UX). */
+export async function ensureMinDelay(startTime: number, minMs = 300) {
+ const elapsed = Date.now() - startTime
+ if (elapsed < minMs)
</file context>
| import { createLegendConfig, createStackedChartScales } from '~/services/chartConfig' | ||
| import { createTooltipConfig } from '~/services/chartTooltip' | ||
| import { generateMonthDays } from '~/services/date' | ||
| import { generateMonthDays, normalizeToUtcStartOfDay } from '~/services/date' |
There was a problem hiding this comment.
P3: The new createTodayLineOptions helper centralizes the today-line styling, but useBuildChartConfig still returns the same inline today-line config with the identical hardcoded colors rather than delegating to the helper. This leaves two copies of the today-line look in the codebase, defeating the PR's dedup goal: future styling changes have to be updated in both places. Consider calling createTodayLineOptions here too (it already replicates the same useBillingPeriod/index guard).
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/composables/useBuildChartConfig.ts, line 7:
<comment>The new `createTodayLineOptions` helper centralizes the today-line styling, but `useBuildChartConfig` still returns the same inline today-line config with the identical hardcoded colors rather than delegating to the helper. This leaves two copies of the today-line look in the codebase, defeating the PR's dedup goal: future styling changes have to be updated in both places. Consider calling `createTodayLineOptions` here too (it already replicates the same `useBillingPeriod`/index guard).</comment>
<file context>
@@ -4,7 +4,7 @@ import { useI18n } from 'vue-i18n'
import { createLegendConfig, createStackedChartScales } from '~/services/chartConfig'
import { createTooltipConfig } from '~/services/chartTooltip'
-import { generateMonthDays } from '~/services/date'
+import { generateMonthDays, normalizeToUtcStartOfDay } from '~/services/date'
import { useOrganizationStore } from '~/stores/organization'
</file context>
| export function getBuildChartWindow(useBillingPeriod: boolean, subscriptionStart?: string | null): BuildChartWindow { | ||
| const todayStart = new Date() | ||
| todayStart.setHours(0, 0, 0, 0) | ||
| const todayStart = normalizeToUtcStartOfDay() |
There was a problem hiding this comment.
P3: The build chart's created_at upper bound changed behavior: the old endOfToday.setHours(23,59,59,999) (end of local day) was removed, so endISO is now the instant the window is built (new Date()), while todayStart moved to UTC midnight. This makes endISO time-of-fetch dependent and no longer 'end of today' as the BuildChartWindow.endISO comment documents, and it isn't aligned with the UTC day boundary that todayStart now uses. Consider restoring the intent by normalizing to the UTC end of day (e.g. endOfToday.setUTCHours(23,59,59,999)) or updating the comment/name to reflect that endISO is now 'fetch time' rather than end of today.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/services/buildCharts.ts, line 62:
<comment>The build chart's created_at upper bound changed behavior: the old `endOfToday.setHours(23,59,59,999)` (end of local day) was removed, so `endISO` is now the instant the window is built (`new Date()`), while `todayStart` moved to UTC midnight. This makes `endISO` time-of-fetch dependent and no longer 'end of today' as the `BuildChartWindow.endISO` comment documents, and it isn't aligned with the UTC day boundary that `todayStart` now uses. Consider restoring the intent by normalizing to the UTC end of day (e.g. `endOfToday.setUTCHours(23,59,59,999)`) or updating the comment/name to reflect that `endISO` is now 'fetch time' rather than end of today.</comment>
<file context>
@@ -57,25 +59,22 @@ export interface BuildChartWindow {
export function getBuildChartWindow(useBillingPeriod: boolean, subscriptionStart?: string | null): BuildChartWindow {
- const todayStart = new Date()
- todayStart.setHours(0, 0, 0, 0)
+ const todayStart = normalizeToUtcStartOfDay()
const endOfToday = new Date()
- endOfToday.setHours(23, 59, 59, 999)
</file context>
Include today's deployments with an exclusive UTC upper bound, keep billing-cycle math on elapsed UTC days, and preserve UTC calendar days for chart click log navigation and date-only billing boundaries. Co-authored-by: Martin DONADIEU <martindonadieu@gmail.com>
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_f38c1f75-ed55-4c5f-85cd-fefb8b73bbf8) |
|
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/dashboard/BundleUploadsCard.vue`:
- Around line 181-186: Update the raw-row caching used by the series-window
query in BundleUploadsCard.vue (lines 181-186) and DeploymentStatsCard.vue
(lines 200-201) so each cache entry is keyed by organization plus the resolved
UTC start and exclusive-end bounds derived from useBillingPeriod, seriesStart,
and exclusiveEnd; ensure calculateStats(false) never reuses rows from a
different window.
In `@src/components/dashboard/LineChartStats.vue`:
- Line 14: In LineChartStats, replace both unresolved getDaysInCurrentMonth
calls with the imported getDaysInCurrentUtcMonth helper, preserving the existing
call arguments and behavior.
In `@src/services/date.ts`:
- Around line 206-213: Update formatUtcDateParam to validate date-only strings
against a real calendar date before constructing the UTC Date, so values such as
2026-02-30 follow the existing empty invalid-date fallback instead of being
normalized. Add a regression test covering 2026-02-30 and preserve valid
date-only formatting.
In `@tests/date.unit.test.ts`:
- Around line 143-145: Update the zone-less ISO regression test for
formatUtcDateParam to run under TZ=America/Los_Angeles, use the
timezone-sensitive input 2026-08-07T23:30:00, and continue expecting 2026-08-07.
Configure the test command or runner environment rather than mutating
process.env.TZ within the suite.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: eeca0302-617a-4478-8383-3a1b242e6532
📒 Files selected for processing (15)
src/components/dashboard/BundleUploadsCard.vuesrc/components/dashboard/BundleUploadsChart.vuesrc/components/dashboard/DeploymentStatsCard.vuesrc/components/dashboard/DeploymentStatsChart.vuesrc/components/dashboard/LineChartStats.vuesrc/components/dashboard/UpdateStatsChart.vuesrc/components/dashboard/Usage.vuesrc/composables/useOrgBillingCycleChart.tssrc/services/dailyChartProps.tssrc/services/dashboardChartRegister.tssrc/services/date.tssrc/stores/organization.tssrc/utils/chartOptimizations.tstests/chart-optimizations.unit.test.tstests/date.unit.test.ts
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
Cap-go/capacitor-updater(manual)
Comment on lines
+181
to
+186
| // Fetch series window (billing cycle or last 30 UTC days) | ||
| const query = useSupabase() | ||
| .from('app_versions') | ||
| .select('created_at, app_id, deleted, r2_path, external_url, user_id') | ||
| .gte('created_at', last30DaysStart.toISOString()) | ||
| .lte('created_at', last30DaysEnd.toISOString()) | ||
| .lt('created_at', last30DaysEnd.toISOString()) |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Key cached raw data by the resolved series window.
Both components cache raw rows only by organization, but the query now depends on useBillingPeriod, seriesStart, and exclusiveEnd. When a user switches views, calculateStats(false) can reuse rows from a different window. This produces missing billing-cycle history or stale out-of-range data.
src/components/dashboard/BundleUploadsCard.vue#L181-L186: Include the resolved UTC bounds in the cache key, or cache a verified superset before filtering.src/components/dashboard/DeploymentStatsCard.vue#L200-L201: Include the resolved UTC bounds in the cache key, or cache a verified superset before filtering.
📍 Affects 2 files
src/components/dashboard/BundleUploadsCard.vue#L181-L186(this comment)src/components/dashboard/DeploymentStatsCard.vue#L200-L201
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/dashboard/BundleUploadsCard.vue` around lines 181 - 186,
Update the raw-row caching used by the series-window query in
BundleUploadsCard.vue (lines 181-186) and DeploymentStatsCard.vue (lines
200-201) so each cache entry is keyed by organization plus the resolved UTC
start and exclusive-end bounds derived from useBillingPeriod, seriesStart, and
exclusiveEnd; ensure calculateStats(false) never reuses rows from a different
window.
| import { useOrganizationStore } from '~/stores/organization' | ||
| import { createTodayLineOptions, getSafeChartHue } from '~/services/chartTodayLine' | ||
| import { registerDashboardCharts } from '~/services/dashboardChartRegister' | ||
| import { generateMonthDays, getCurrentDayMonth, getDaysInCurrentUtcMonth } from '~/services/date' |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
ast-grep outline src/components/dashboard/LineChartStats.vue --items all
rg -n -C 2 'getDaysInCurrent(?:Utc)?Month\s*\(' src/components/dashboard/LineChartStats.vueRepository: Cap-go/capgo.app
Length of output: 977
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- LineChartStats.vue ---'
sed -n '1,170p' src/components/dashboard/LineChartStats.vue
printf '%s\n' '--- date-service declarations and usages ---'
rg -n -C 3 'getDaysInCurrent(?:Utc)?Month|export .*getCurrentDayMonth|generateMonthDays' srcRepository: Cap-go/capgo.app
Length of output: 18274
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- date helpers ---'
sed -n '105,148p' src/services/date.ts
printf '%s\n' '--- focused diff ---'
git diff -- src/components/dashboard/LineChartStats.vue src/services/date.ts
printf '%s\n' '--- exact identifier/import check ---'
python3 - <<'PY'
from pathlib import Path
import re
path = Path('src/components/dashboard/LineChartStats.vue')
text = path.read_text()
imports = set(re.findall(r'\b(?:generateMonthDays|getCurrentDayMonth|getDaysInCurrentUtcMonth|getDaysInCurrentMonth)\b', text.split('</script>', 1)[0]))
calls = re.findall(r'\b(getDaysInCurrent(?:Utc)?Month)\s*\(', text)
print('identifiers in script:', sorted(imports))
print('month-length calls:', calls)
print('getDaysInCurrentMonth imported:', bool(re.search(r'import\s*\{[^}]*\bgetDaysInCurrentMonth\b[^}]*\}\s*from', text, re.S)))
PYRepository: Cap-go/capgo.app
Length of output: 1921
Replace the unresolved month-length helper.
getDaysInCurrentMonth is not imported. Replace both calls with the already imported getDaysInCurrentUtcMonth so the component compiles.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/dashboard/LineChartStats.vue` at line 14, In LineChartStats,
replace both unresolved getDaysInCurrentMonth calls with the imported
getDaysInCurrentUtcMonth helper, preserving the existing call arguments and
behavior.
Comment on lines
+206
to
+213
| export function formatUtcDateParam(date: Date | string = new Date()) { | ||
| let parsed: Date | ||
| if (typeof date === 'string' && DATE_ONLY_RE.test(date)) | ||
| parsed = new Date(`${date}T00:00:00.000Z`) | ||
| else if (typeof date === 'string' && ZONELESS_ISO_DATETIME_RE.test(date)) | ||
| parsed = new Date(`${date}Z`) | ||
| else | ||
| parsed = new Date(date) |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Reject calendar-invalid date-only parameters.
new Date('2026-02-30T00:00:00.000Z') normalizes to March 2. This function returns 2026-03-02 instead of its empty invalid-date fallback. Validate date-only fields before formatting. Add a regression test for 2026-02-30.
Proposed fix
export function formatUtcDateParam(date: Date | string = new Date()) {
+ if (typeof date === 'string' && DATE_ONLY_RE.test(date)) {
+ const parsed = parseUtcRangeBoundary(date)
+ return parsed ? parsed.toISOString().slice(0, 10) : ''
+ }
+
let parsed: Date
- if (typeof date === 'string' && DATE_ONLY_RE.test(date))
- parsed = new Date(`${date}T00:00:00.000Z`)
- else if (typeof date === 'string' && ZONELESS_ISO_DATETIME_RE.test(date))
+ if (typeof date === 'string' && ZONELESS_ISO_DATETIME_RE.test(date))
parsed = new Date(`${date}Z`)
else
parsed = new Date(date)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| export function formatUtcDateParam(date: Date | string = new Date()) { | |
| let parsed: Date | |
| if (typeof date === 'string' && DATE_ONLY_RE.test(date)) | |
| parsed = new Date(`${date}T00:00:00.000Z`) | |
| else if (typeof date === 'string' && ZONELESS_ISO_DATETIME_RE.test(date)) | |
| parsed = new Date(`${date}Z`) | |
| else | |
| parsed = new Date(date) | |
| export function formatUtcDateParam(date: Date | string = new Date()) { | |
| if (typeof date === 'string' && DATE_ONLY_RE.test(date)) { | |
| const parsed = parseUtcRangeBoundary(date) | |
| return parsed ? parsed.toISOString().slice(0, 10) : '' | |
| } | |
| let parsed: Date | |
| if (typeof date === 'string' && ZONELESS_ISO_DATETIME_RE.test(date)) | |
| parsed = new Date(`${date}Z`) | |
| else | |
| parsed = new Date(date) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/services/date.ts` around lines 206 - 213, Update formatUtcDateParam to
validate date-only strings against a real calendar date before constructing the
UTC Date, so values such as 2026-02-30 follow the existing empty invalid-date
fallback instead of being normalized. Add a regression test covering 2026-02-30
and preserve valid date-only formatting.
Comment on lines
+143
to
+145
| it('treats zone-less ISO datetimes as UTC in formatUtcDateParam', () => { | ||
| expect(formatUtcDateParam('2026-08-07T15:30:00')).toBe('2026-08-07') | ||
| }) |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
fd -HI -t f '^(package\.json|vitest\.config\..*|vite\.config\..*)$' . \
-x sh -c 'printf "\n### %s\n" "$1"; rg -n -C 3 "vitest|test|TZ" "$1" || true' sh {}Repository: Cap-go/capgo.app
Length of output: 28473
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '### tests/date.unit.test.ts'
sed -n '1,190p' tests/date.unit.test.ts
printf '%s\n' '### date helpers and usages'
rg -n -C 5 "formatUtcDateParam|formatUtc|DateParam" src tests --glob '*.{ts,tsx,vue}' || true
printf '%s\n' '### timezone-sensitive runtime probe'
TZ=America/Los_Angeles node - <<'JS'
const input = '2026-08-07T23:30:00'
const local = new Date(input)
const utc = new Date(`${input}Z`)
const day = date => date.toISOString().slice(0, 10)
console.log(JSON.stringify({
timezone: process.env.TZ,
localISO: local.toISOString(),
utcISO: utc.toISOString(),
localDay: day(local),
utcDay: day(utc),
}))
JSRepository: Cap-go/capgo.app
Length of output: 24651
Make the zone-less ISO regression test timezone-sensitive.
The current 15:30:00 input does not distinguish UTC parsing from local parsing. Run an equivalent assertion with TZ=America/Los_Angeles and 2026-08-07T23:30:00, expecting 2026-08-07. Do not mutate process.env.TZ inside this suite.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@tests/date.unit.test.ts` around lines 143 - 145, Update the zone-less ISO
regression test for formatUtcDateParam to run under TZ=America/Los_Angeles, use
the timezone-sensitive input 2026-08-07T23:30:00, and continue expecting
2026-08-07. Configure the test command or runner environment rather than
mutating process.env.TZ within the suite.
Source: Coding guidelines
There was a problem hiding this comment.
5 issues found across 15 files (changes from recent commits).
Confidence score: 2/5
src/components/dashboard/LineChartStats.vuestill callsgetDaysInCurrentMonthwithout importing it, which can break the dashboard build immediately and block release validation—restore the import or finish migrating those call sites to the UTC helper.src/components/dashboard/DeploymentStatsCard.vue,src/components/dashboard/BundleUploadsCard.vue, andsrc/utils/chartOptimizations.tsshare a cache-window mismatch: rows fetched for one date range are reused for another, which can drop early-cycle days or shift daily counts when users switch billing modes—key/invalidate cache entries by start/end window (and app scope) before reindexing.src/utils/chartOptimizations.tsreindexes cached rows with a newseriesStartafter mode switches, so edge days can be added/dropped and per-day totals misaligned in charts—persist fetched window metadata and force refetch when the active range changes.src/components/dashboard/UpdateStatsChart.vuesends an end timestamp that the backend treats as exclusive, so log drill-downs can miss events at the end of the selected UTC day—send the next midnight asendto include the full day reliably.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/components/dashboard/LineChartStats.vue">
<violation number="1" location="src/components/dashboard/LineChartStats.vue:14">
P1: Dashboard build fails because `getDaysInCurrentMonth` is still used but no longer imported. Keep that import (or migrate both remaining call sites) with the UTC helper.</violation>
</file>
<file name="src/components/dashboard/DeploymentStatsCard.vue">
<violation number="1" location="src/components/dashboard/DeploymentStatsCard.vue:140">
P1: Switching from the default 30-day view to a billing cycle longer than 30 days omits early-cycle deployments because the per-org cache is reused despite its narrower query window. Store/query cache coverage with the range or force a refetch when billing mode needs an earlier `seriesStart`.</violation>
</file>
<file name="src/components/dashboard/BundleUploadsCard.vue">
<violation number="1" location="src/components/dashboard/BundleUploadsCard.vue:126">
P1: Switching from billing-cycle to 30-day mode can omit earlier days because cache entries are keyed only by org although this new window changes the query range. Key or invalidate cached rows by series window (and app set), or force a refetch when `useBillingPeriod` changes.</violation>
</file>
<file name="src/components/dashboard/UpdateStatsChart.vue">
<violation number="1" location="src/components/dashboard/UpdateStatsChart.vue:89">
P2: Logs clicked from a chart can omit events in the selected UTC day’s final millisecond because the backend treats `rangeEnd` as exclusive. Send the following midnight as `end` instead.</violation>
</file>
<file name="src/utils/chartOptimizations.ts">
<violation number="1" location="src/utils/chartOptimizations.ts:52">
P1: Switching billing mode reuses rows fetched for the prior window but reindexes them using this new `seriesStart`, shifting daily counts (and dropping/adding edge days). Cache the fetched window with its start/end or force a refetch when `useBillingPeriod` changes.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| import { useOrganizationStore } from '~/stores/organization' | ||
| import { createTodayLineOptions, getSafeChartHue } from '~/services/chartTodayLine' | ||
| import { registerDashboardCharts } from '~/services/dashboardChartRegister' | ||
| import { generateMonthDays, getCurrentDayMonth, getDaysInCurrentUtcMonth } from '~/services/date' |
There was a problem hiding this comment.
P1: Dashboard build fails because getDaysInCurrentMonth is still used but no longer imported. Keep that import (or migrate both remaining call sites) with the UTC helper.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/components/dashboard/LineChartStats.vue, line 14:
<comment>Dashboard build fails because `getDaysInCurrentMonth` is still used but no longer imported. Keep that import (or migrate both remaining call sites) with the UTC helper.</comment>
<file context>
@@ -11,7 +11,7 @@ import { useDashboardDailyChartCycle } from '~/composables/useOrgBillingCycleCha
import { createTodayLineOptions, getSafeChartHue } from '~/services/chartTodayLine'
import { registerDashboardCharts } from '~/services/dashboardChartRegister'
-import { generateMonthDays, getCurrentDayMonth, getDaysInCurrentMonth } from '~/services/date'
+import { generateMonthDays, getCurrentDayMonth, getDaysInCurrentUtcMonth } from '~/services/date'
import { inlineAnnotationPlugin } from '../../services/chartAnnotations'
import { createTooltipConfig, todayLinePlugin, verticalLinePlugin } from '../../services/chartTooltip'
</file context>
Suggested change
| import { generateMonthDays, getCurrentDayMonth, getDaysInCurrentUtcMonth } from '~/services/date' | |
| import { generateMonthDays, getCurrentDayMonth, getDaysInCurrentMonth, getDaysInCurrentUtcMonth } from '~/services/date' |
| const billingStart = new Date(targetOrganization.subscription_start ?? new Date()) | ||
| billingStart.setHours(0, 0, 0, 0) | ||
| const billingStart = normalizeToUtcStartOfDay(new Date(targetOrganization.subscription_start ?? new Date())) | ||
| const { seriesStart: last30DaysStart, exclusiveEnd, dayCount } = resolveDashboardDailySeriesWindow( |
There was a problem hiding this comment.
P1: Switching from the default 30-day view to a billing cycle longer than 30 days omits early-cycle deployments because the per-org cache is reused despite its narrower query window. Store/query cache coverage with the range or force a refetch when billing mode needs an earlier seriesStart.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/components/dashboard/DeploymentStatsCard.vue, line 140:
<comment>Switching from the default 30-day view to a billing cycle longer than 30 days omits early-cycle deployments because the per-org cache is reused despite its narrower query window. Store/query cache coverage with the range or force a refetch when billing mode needs an earlier `seriesStart`.</comment>
<file context>
@@ -135,15 +135,16 @@ async function calculateStats(forceRefetch = false) {
-
// Get billing period dates for filtering
const billingStart = normalizeToUtcStartOfDay(new Date(targetOrganization.subscription_start ?? new Date()))
+ const { seriesStart: last30DaysStart, exclusiveEnd, dayCount } = resolveDashboardDailySeriesWindow(
+ props.useBillingPeriod,
+ billingStart,
</file context>
| billingStart.setHours(0, 0, 0, 0) | ||
| const billingStart = normalizeToUtcStartOfDay(new Date(organizationStore.currentOrganization?.subscription_start ?? new Date())) | ||
| const { seriesStart: last30DaysStart, exclusiveEnd: last30DaysEnd, dayCount } = resolveDashboardDailySeriesWindow( | ||
| props.useBillingPeriod, |
There was a problem hiding this comment.
P1: Switching from billing-cycle to 30-day mode can omit earlier days because cache entries are keyed only by org although this new window changes the query range. Key or invalidate cached rows by series window (and app set), or force a refetch when useBillingPeriod changes.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/components/dashboard/BundleUploadsCard.vue, line 126:
<comment>Switching from billing-cycle to 30-day mode can omit earlier days because cache entries are keyed only by org although this new window changes the query range. Key or invalidate cached rows by series window (and app set), or force a refetch when `useBillingPeriod` changes.</comment>
<file context>
@@ -120,12 +120,12 @@ async function calculateStats(forceRefetch = false) {
// Get billing period dates for filtering
const billingStart = normalizeToUtcStartOfDay(new Date(organizationStore.currentOrganization?.subscription_start ?? new Date()))
+ const { seriesStart: last30DaysStart, exclusiveEnd: last30DaysEnd, dayCount } = resolveDashboardDailySeriesWindow(
+ props.useBillingPeriod,
+ billingStart,
+ )
</file context>
| if (useBillingPeriod && !Number.isNaN(cycleStart.getTime())) { | ||
| const elapsedDays = Math.floor((todayUtc.getTime() - cycleStart.getTime()) / DAY_MS) | ||
| if (elapsedDays >= 0 && elapsedDays <= 366) | ||
| seriesStart = cycleStart |
There was a problem hiding this comment.
P1: Switching billing mode reuses rows fetched for the prior window but reindexes them using this new seriesStart, shifting daily counts (and dropping/adding edge days). Cache the fetched window with its start/end or force a refetch when useBillingPeriod changes.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/utils/chartOptimizations.ts, line 52:
<comment>Switching billing mode reuses rows fetched for the prior window but reindexes them using this new `seriesStart`, shifting daily counts (and dropping/adding edge days). Cache the fetched window with its start/end or force a refetch when `useBillingPeriod` changes.</comment>
<file context>
@@ -20,33 +22,62 @@ export function incrementArrayValue(arr: (number | undefined)[], index: number,
+ if (useBillingPeriod && !Number.isNaN(cycleStart.getTime())) {
+ const elapsedDays = Math.floor((todayUtc.getTime() - cycleStart.getTime()) / DAY_MS)
+ if (elapsedDays >= 0 && elapsedDays <= 366)
+ seriesStart = cycleStart
}
</file context>
| params.set('end', endOfDay.toISOString()) | ||
| const { start, end } = getUtcDayBounds(clickContext.date) | ||
| params.set('start', start.toISOString()) | ||
| params.set('end', end.toISOString()) |
There was a problem hiding this comment.
P2: Logs clicked from a chart can omit events in the selected UTC day’s final millisecond because the backend treats rangeEnd as exclusive. Send the following midnight as end instead.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/components/dashboard/UpdateStatsChart.vue, line 89:
<comment>Logs clicked from a chart can omit events in the selected UTC day’s final millisecond because the backend treats `rangeEnd` as exclusive. Send the following midnight as `end` instead.</comment>
<file context>
@@ -83,12 +82,11 @@ const tooltipClickHandler = computed<TooltipClickHandler | undefined>(() => {
- params.set('end', endOfDay.toISOString())
+ const { start, end } = getUtcDayBounds(clickContext.date)
+ params.set('start', start.toISOString())
+ params.set('end', end.toISOString())
}
</file context>
Suggested change
| params.set('end', end.toISOString()) | |
| params.set('end', new Date(end.getTime() + 1).toISOString()) |
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
2 participants
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.
Summary (AI generated)
Legendregistration, reactive cycle ends for expired subscriptions.Motivation (AI generated)
Brazil customers saw today’s device/stats after a release; Capgo (Europe) viewing the same org only saw through yesterday. Local midnight +
toISOString()shifted the UTC day for positive offsets. Review bots also flagged remaining UTC edge cases that could drop today’s deployments or mis-size billing charts.Business Impact (AI generated)
Dashboard “today” and billing-period charts stay consistent worldwide for the same org, avoiding false “missing data” support issues around timezone boundaries.
Test Plan (AI generated)
from/toend on the same UTC dayGenerated with AI
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by CodeRabbit
Bug Fixes
Refactor