Fix: Show data for the last day of the month for usage graphs #1999
Conversation
|
WalkthroughThe update modifies the way the number of periods between a start and end date is calculated within a utility file. Specifically, it changes the method from always rounding down to the nearest whole number to rounding to the nearest whole number, which could affect how intervals are determined in time-based calculations. Changes
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/webapp/app/utils/graphs.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (7)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: units / 🧪 Unit Tests
- GitHub Check: Analyze (javascript-typescript)
| @@ -8,7 +8,7 @@ type Options<R> = { | |||
| export function createTimeSeriesData<R>({ startDate, endDate, window = "DAY", data }: Options<R>) { | |||
| const outputData: Array<{ date: Date; value?: R }> = []; | |||
| const periodLength = periodLengthMs(window); | |||
| const periodCount = Math.floor((endDate.getTime() - startDate.getTime()) / periodLength); | |||
| const periodCount = Math.round((endDate.getTime() - startDate.getTime()) / periodLength); | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Logic improved to include last day of the month
The change from Math.floor to Math.round fixes the issue where the last day of the month might be cut off in usage graphs. This correctly aligns with the PR objective.
Previously, if there was a partial period at the end of the date range, it would always be truncated. Now, if that partial period is at least half complete, it will be included in the output data.
You might want to verify this behavior with a simple test to ensure it works as expected:
🏁 Script executed:
#!/bin/bash
# Find any existing tests for this function
rg "createTimeSeriesData" --type ts --type tsxLength of output: 74
🏁 Script executed:
#!/bin/bash
# Search for createTimeSeriesData definition across TS/TSX files
rg --context 2 "function createTimeSeriesData" -g '*.ts' -g '*.tsx'
# Search for any test files referencing createTimeSeriesData
rg --context 2 "createTimeSeriesData" -g '*.spec.ts' -g '*.test.ts'Length of output: 507
🏁 Script executed:
#!/bin/bash
# Retrieve relevant code around periodCount in createTimeSeriesData
rg --context 5 "const periodCount" -g 'apps/webapp/app/utils/graphs.ts'
# Locate periodLengthMs function definition to understand periodLength calculation
rg --context 5 "function periodLengthMs" -g 'apps/webapp/app/utils/graphs.ts'Length of output: 1544
Add unit tests for the updated rounding logic
We switched from Math.floor to Math.round so that any partial period ≥50% is now included in the output. However, there are no existing tests for createTimeSeriesData, so we can’t automatically verify the new behavior. Please add a test suite covering boundary conditions:
• File: apps/webapp/app/utils/graphs.ts
const periodCount = Math.round((endDate.getTime() - startDate.getTime()) / periodLength);• Scenarios to cover:
- Exact multiples of a period (e.g. 24h → 1 day)
- Partial period just under 50% (e.g. 11h for a 24h window → expect 0 days)
- Partial period just over 50% (e.g. 13h for a 24h window → expect 1 day)
- Each window type (“MINUTE”, “HOUR”, “DAY”)
- Very short ranges (<50% of one period)
Adding these will ensure the rounding change behaves correctly across all cases.
Fix for #1997
Summary by CodeRabbit