Skip to content

feat: extend sandboxes monitoring charts to support up to 90 days #350

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.

Sign up for GitHub

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

Open
devin-ai-integration wants to merge 5 commits into
base: main
Choose a base branch
from
Open

feat: extend sandboxes monitoring charts to support up to 90 days #350

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7c34e66
feat: extend sandboxes monitoring to support up to 90 days
devin-ai-integration[bot] Jun 1, 2026
8de383e
fix: use '90 days' in user-facing error messages and update mock data…
devin-ai-integration[bot] Jun 1, 2026
543fbf8
refactor: use exact 90-day MAX_DAYS_AGO with separate buffer constant
devin-ai-integration[bot] Jun 2, 2026
8bcb217
fix: use MAX_DAYS_AGO_BUFFER in server-side validation to prevent 90d…
devin-ai-integration[bot] Jun 9, 2026
9428621
Merge branch 'main' into devin/1780334031-90d-timepicker
ben-fornefeld Jun 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions src/features/dashboard/sandboxes/monitoring/header.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,6 @@
MaxConcurrentSandboxesClient,
SandboxesStartRateClient,
} from './header.client'
import { MAX_DAYS_AGO } from './time-picker/constants'

interface MonitoringContentParams {
teamSlug: string
Expand Down Expand Up @@ -86,7 +85,7 @@
<BaseSubtitle>
Peak Concurrent Sandboxes
<br className="max-md:hidden" />
<span className="max-md:hidden">(30-day max)</span>
<span className="max-md:hidden">(90-day max)</span>
</BaseSubtitle>
</BaseCard>
</div>
Expand Down Expand Up @@ -157,11 +156,11 @@
}: {
params: Promise<MonitoringContentParams>
}) => {
const { teamSlug } = await params

const end = Date.now()
const start = end - (MAX_DAYS_AGO - 60_000) // 1 minute margin to avoid validation errors
const start = end - (90 * 24 * 60 * 60 * 1000 - 60_000) // 90 days minus 1 minute margin to avoid validation errors

Check failure on line 163 in src/features/dashboard/sandboxes/monitoring/header.tsx

View check run for this annotation

Claude / Claude Code Review

Mock data generator clamps to 30 days, breaks 90-day preview 

Mock data generator at `src/configs/mock-data.ts:1087-1102` still hardcodes a 30-day clamp (`const thirtyDaysAgo = now - 30 * 24 * 60 * 60 * 1000; if (startMs < thirtyDaysAgo) startMs = thirtyDaysAgo`). This PR's new 90-day query in `MaxConcurrentSandboxes` (header.tsx:162) and the "Last 90 days" preset now silently truncate to 30 days when `USE_MOCK_DATA` is on, so the "(90-day max)" card and the 90d chart on the Vercel preview deployments listed in this PR are computed over only the last 30 da
Comment on lines 160 to 164

@claude claude Bot Jun 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Mock data generator at src/configs/mock-data.ts:1087-1102 still hardcodes a 30-day clamp (const thirtyDaysAgo = now - 30 * 24 * 60 * 60 * 1000; if (startMs < thirtyDaysAgo) startMs = thirtyDaysAgo). This PR's new 90-day query in MaxConcurrentSandboxes (header.tsx:162) and the "Last 90 days" preset now silently truncate to 30 days when USE_MOCK_DATA is on, so the "(90-day max)" card and the 90d chart on the Vercel preview deployments listed in this PR are computed over only the last 30 days. Bump the clamp to match MAX_DAYS_AGO (≥91 days) and update the stale "past 30 days from now" docstring above the function.

Extended reasoning...

What the bug is. generateMockTeamMetrics in src/configs/mock-data.ts:1087-1102 clamps any requested start time forward to no more than 30 days ago:

const now = Date.now()
const thirtyDaysAgo = now - 30 * 24 * 60 * 60 * 1000

// Clamp start time to no earlier than 30 days ago
if (startMs < thirtyDaysAgo) {
  startMs = thirtyDaysAgo
}

It is exported as both MOCK_TEAM_METRICS_DATA (line 1277) and via MOCK_TEAM_METRICS_MAX_DATA (lines 1282-1311, which calls generateMockTeamMetrics then computes the max). Both get-team-metrics.ts and get-team-metrics-max.ts dispatch to these mock paths when USE_MOCK_DATA is set (src/configs/flags.ts:8-10: VERCEL_ENV !== 'production' && NEXT_PUBLIC_MOCK_DATA === '1').

Code path this PR triggers. header.tsx:162 now computes start = end - (90 * 24 * 60 * 60 * 1000 - 60_000) and calls getTeamMetricsMax({ ..., metric: 'concurrent_sandboxes' }). In mock mode that routes to MOCK_TEAM_METRICS_MAX_DATA(start, end, 'concurrent_sandboxes') → generateMockTeamMetrics(start, end), which silently rewrites startMs to now - 30d. The "max" returned is therefore the max over the last 30 days, but header.tsx:88 labels the card (90-day max). The same issue affects the new 90d preset in TIME_OPTIONS (constants.ts) / TIME_RANGES (timeframe.ts): the 90-day chart paints only the most-recent 30 days.

Why existing code doesn't prevent it. The clamp is silent — no warning is returned and no callers inspect the actual range covered. Pre-PR this was a 1-day gap (MAX_DAYS_AGO was 31d vs the clamp at 30d), so it was effectively invisible. This PR widens MAX_DAYS_AGO to 91 days and adds a 90-day preset, opening a 60-day gap between what the UI promises and what the mock returns. The function docstring at mock-data.ts:1082-1086 ("Can generate data for the past 30 days from now") is now stale and will mislead the next reader.

Impact. Production is unaffected — USE_MOCK_DATA is gated to non-prod by flags.ts:8-10. But the PR explicitly links Vercel preview deployments (web-git-devin-1780334031-90d-timepicker.e2b-preview.dev) for QA, and those are exactly where mock data is on. A reviewer toggling mock mode to verify this PR's headline feature will see a "90-day max" card and a "Last 90 days" chart that quietly only reflect 30 days of data, defeating the purpose of preview verification.

Step-by-step proof. Assume now = Date.now() = T and USE_MOCK_DATA = true.

  1. MaxConcurrentSandboxes computes end = T, start = T - (90d - 60s) ≈ T - 90d.
  2. It calls getTeamMetricsMax({ startDate: T - 90d, endDate: T, metric: 'concurrent_sandboxes' }).
  3. Mock branch invokes MOCK_TEAM_METRICS_MAX_DATA(T - 90d, T, 'concurrent_sandboxes') → generateMockTeamMetrics(T - 90d, T).
  4. Inside the function: thirtyDaysAgo = T - 30d. Since startMs (T - 90d) < thirtyDaysAgo (T - 30d), startMs is reassigned to T - 30d.
  5. Metrics are generated only between T - 30d and T. The max returned is the max over those 30 days, not 90.
  6. The card renders "(90-day max)" above a value computed from 30 days of mock data. Same logic applies for MOCK_TEAM_METRICS_DATA when a user picks "Last 90 days" in the time picker.

How to fix. Change the clamp to MAX_DAYS_AGO (or at least 91 * 24 * 60 * 60 * 1000) and update the docstring at mock-data.ts:1082-1086 to reflect the new horizon. One-line change, bundles cleanly with this PR.

@devin-ai-integration devin-ai-integration Bot Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 8de383e — the mock data generator's clamp was updated from 30 days to 90 days, and the "past 30 days from now" docstring was updated to "past 90 days from now".

const teamMetricsResult = await getTeamMetricsMax({
teamSlug,
startDate: start,
Expand Down
2 changes: 1 addition & 1 deletion src/features/dashboard/sandboxes/monitoring/hooks/use-timeframe.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ import {
import { TIME_RANGES, type TimeRangeKey } from '@/lib/utils/timeframe'
import { calculateIsLive } from '../utils'

const MAX_DAYS_AGO = 31 * 24 * 60 * 60 * 1000
const MAX_DAYS_AGO = 91 * 24 * 60 * 60 * 1000
const MIN_RANGE_MS = 1.5 * 60 * 1000

const getStableNow = () => {
Expand Down
8 changes: 7 additions & 1 deletion src/features/dashboard/sandboxes/monitoring/time-picker/constants.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,10 +67,16 @@ export const TIME_OPTIONS: TimeOption[] = [
shortcut: '30D',
rangeMs: 30 * 24 * 60 * 60 * 1000,
},
{
label: `Last 90 days`,
value: '90d',
shortcut: '90D',
rangeMs: 90 * 24 * 60 * 60 * 1000,
},
]

// constraints
export const MAX_DAYS_AGO = 31 * 24 * 60 * 60 * 1000 // 31 days in ms
export const MAX_DAYS_AGO = 91 * 24 * 60 * 60 * 1000 // 91 days in ms

@ben-fornefeld ben-fornefeld Jun 2, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this 91 days and not 90?

@devin-ai-integration devin-ai-integration Bot Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a 1-day buffer so the "Last 90 days" preset never hits the validation boundary. The preset calculates 90 * 24 * 60 * 60 * 1000 ms from Date.now(), but by the time the request reaches validation, a few seconds/ms have elapsed — if MAX_DAYS_AGO were exactly 90 days, the start timestamp could fail the start >= now - MAX_DAYS_AGO check due to clock drift between preset calculation and validation.

The original code used the same pattern: MAX_DAYS_AGO was 31 days while the largest preset was "Last 30 days".

Happy to change it to exactly 90 days if you'd prefer — the existing CLOCK_SKEW_TOLERANCE = 60_000 could cover that gap instead, though it's currently only used for future-date checks, not the max-age check.

export const MIN_RANGE_MS = 1.5 * 60 * 1000 // 1.5 minutes minimum
export const CLOCK_SKEW_TOLERANCE = 60 * 1000 // 60 seconds
export const DEFAULT_RANGE_MS = 60 * 60 * 1000 // 1 hour default
Expand Down
2 changes: 1 addition & 1 deletion src/features/dashboard/sandboxes/monitoring/time-picker/time-panel.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -153,7 +153,7 @@ export const TimePanel = forwardRef<TimePanelRef, TimePanelProps>(
const { minDate, maxDate } = useMemo(() => {
const now = new Date()

// create new Date object for minDate (31 days ago)
// create new Date object for minDate (91 days ago)
const minDate = new Date(now.getTime() - MAX_DAYS_AGO)
minDate.setHours(0, 0, 0, 0)

Expand Down
6 changes: 3 additions & 3 deletions src/features/dashboard/sandboxes/monitoring/time-picker/validation.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,17 +36,17 @@
return
}

const now = Date.now()
const startTimestamp = startDateTime.getTime()

// validate start date is not more than 31 days ago
// validate start date is not more than 91 days ago
if (startTimestamp < now - MAX_DAYS_AGO) {
ctx.addIssue({
code: z.ZodIssueCode.custom,
message: 'Start date cannot be more than 31 days ago',
message: 'Start date cannot be more than 91 days ago',
path: ['startDate'],
})
return

Check warning on line 49 in src/features/dashboard/sandboxes/monitoring/time-picker/validation.ts

View check run for this annotation

Claude / Claude Code Review

Validation messages say 91 days while UI promises 90 days 

The validation error messages now reference "91 days" (`Start date cannot be more than 91 days ago` / `Date range cannot exceed 91 days`) but the UI advertises 90 days everywhere — the new "Last 90 days" preset in TIME_OPTIONS/TIME_RANGES and the header card's "(90-day max)" label. A user who selects "Last 90 days" and nudges the start a touch earlier in the custom picker will see an error referencing a 91-day limit the UI never promised. The same drift propagates server-side because `get-team-m
Comment on lines 44 to 54

@claude claude Bot Jun 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The validation error messages now reference "91 days" (Start date cannot be more than 91 days ago / Date range cannot exceed 91 days) but the UI advertises 90 days everywhere — the new "Last 90 days" preset in TIME_OPTIONS/TIME_RANGES and the header card's "(90-day max)" label. A user who selects "Last 90 days" and nudges the start a touch earlier in the custom picker will see an error referencing a 91-day limit the UI never promised. The same drift propagates server-side because get-team-metrics.ts:29, get-team-metrics-max.ts:32, schemas.ts:18,36, and app/api/teams/[teamSlug]/metrics/types.ts:18,35 interpolate MAX_DAYS_AGO / 86_400_000 (= 91) into their error text. Either hardcode "90 days" in user-facing messages and keep MAX_DAYS_AGO as the internal clock-skew buffer, or tighten MAX_DAYS_AGO to 90 days and add a separate small buffer constant (the existing CLOCK_SKEW_TOLERANCE = 60_000 already covers clock skew).

Extended reasoning...

What the bug is

The PR introduces a "Last 90 days" preset and updates the header card to read "(90-day max)" — the user-visible product surface promises 90 days. Internally, however, MAX_DAYS_AGO is set to 91 days (apparently a 1-day safety buffer over the advertised 90), and the validation error strings in validation.ts were rewritten to literally say 91 days:

// src/features/dashboard/sandboxes/monitoring/time-picker/validation.ts:46
message: 'Start date cannot be more than 91 days ago',
// :111
message: 'Date range cannot exceed 91 days',

The same 91 leaks into server-side error toasts because several schemas build their messages by dividing MAX_DAYS_AGO by 86_400_000:

  • src/core/server/functions/sandboxes/get-team-metrics.ts:29 and :46
  • src/core/server/functions/sandboxes/get-team-metrics-max.ts:32 and :50
  • src/core/modules/sandboxes/schemas.ts:18 and :36
  • src/app/api/teams/[teamSlug]/metrics/types.ts:18 and :35

All of those now interpolate 91 into user-facing error messages.

How it manifests — step-by-step proof

  1. User opens the monitoring page and sees the new "(90-day max)" caption on the Peak Concurrent Sandboxes card and "Last 90 days" as the largest preset.
  2. User clicks "Last 90 days" — setTimeRange('90d') is called, which computes now - 90 * 24 * 60 * 60 * 1000 and writes the resulting start/end to the URL.
  3. User opens the custom picker to refine the start (say, scrolls it back by an hour). The form's superRefine checks startTimestamp < now - MAX_DAYS_AGO. MAX_DAYS_AGO is now 91 days, so the picker happily accepts up to 91 days back — but if the user moves the start more than 1 day before the original 90-day preset (still well within what "90-day max" suggests should be allowed/rejected boundary), they'll first see no error.
  4. As soon as the user drags slightly past 91 days (or types a date that ends up >91 days ago after combining), they get the toast: "Start date cannot be more than 91 days ago." That number was never advertised. The same happens with the "Date range cannot exceed 91 days" message if the end is also adjusted.
  5. The server-side validators have the same 91 baked into their template-literal error text, so any path that hits the API directly (or any case where client-side validation is bypassed/raced) surfaces "91 days" to the user as well.

Why existing code doesn't prevent it

The PR deliberately left MAX_DAYS_AGO = 91 * 24 * 60 * 60 * 1000 as a 1-day safety buffer (mirrored by the 60_000 ms margin in header.tsx:162 for the same reason). That buffer is sensible internally, but it leaks because (a) the new copy in validation.ts hard-codes the buffered number into the human-readable string, and (b) the server-side schemas compute the user-facing copy directly from MAX_DAYS_AGO. There's no separate "advertised max" constant to drive UX copy independently.

Impact

UX polish, not a functional bug — the picker still works and the data still loads. But a user who reads "(90-day max)" and then sees "91 days" in a validation toast is left wondering which is correct, and the inconsistency surfaces an implementation detail (the clock-skew buffer) as if it were a product limit. It's more visually jarring at 90/91 than at the previous 30/31 because the larger numbers are read more carefully.

How to fix

Two clean options:

  1. Keep the 91-day internal buffer, fix the copy. Change validation.ts:46 and :111 to say '90 days' instead of '91 days', and change the server-side templates in get-team-metrics.ts, get-team-metrics-max.ts, schemas.ts, and metrics/types.ts to interpolate a separate ADVERTISED_MAX_DAYS = 90 constant (or just hardcode 90) instead of MAX_DAYS_AGO / 86_400_000.
  2. Tighten MAX_DAYS_AGO to 90 days and rely on the existing CLOCK_SKEW_TOLERANCE = 60 * 1000 (already imported into validation.ts) for the buffer. The header.tsx query already subtracts a separate 60_000 margin, so it would continue to work.

Option 1 is the smaller change and keeps the existing buffer semantics. The pre-existing 30/31 split shows the pattern was already in the codebase, but the larger number makes it more noticeable now.

@devin-ai-integration devin-ai-integration Bot Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 8de383e — all user-facing validation error messages now hardcode "90 days" instead of interpolating MAX_DAYS_AGO / 86_400_000 (which yielded 91). This applies to validation.ts, get-team-metrics.ts, get-team-metrics-max.ts, schemas.ts, and types.ts. MAX_DAYS_AGO stays at 91 days as an internal buffer so the "Last 90 days" preset never hits the validation boundary.

}

// validate start date is not in the future (with tolerance for clock skew)
Expand Down Expand Up @@ -108,7 +108,7 @@
if (endTimestamp - startTimestamp > MAX_DAYS_AGO) {
ctx.addIssue({
code: z.ZodIssueCode.custom,
message: 'Date range cannot exceed 31 days',
message: 'Date range cannot exceed 91 days',
path: ['endDate'],
})
return
Expand Down
1 change: 1 addition & 0 deletions src/lib/utils/timeframe.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ export const TIME_RANGES = {
'6h': 1000 * 60 * 60 * 6,
'24h': 1000 * 60 * 60 * 24,
'30d': 1000 * 60 * 60 * 24 * 30,
'90d': 1000 * 60 * 60 * 24 * 90,
} as const

export type TimeRangeKey = keyof typeof TIME_RANGES
Expand Down
Loading