fix(metrics): make minute/second date ranges resolve — and roll from now - #68081
Conversation
The metrics viewer's 'Last 5 minutes' / 'Last 30 minutes' options rendered 'No data' while the API returned rows for the same window. Two defects in the shared relative-date helper: - isStringDateRegex only accepted [hdwmqy], but dateOptionsMap promises M (minute) and s (second). '-30M' failed the regex, resolveDate returned null, and the viewer's loader silently returned [] — 'No data'. - dateStringToDayJs anchored every relative date at startOf(day), so even a parsing '-30M' would mean 'today 00:00 minus 30 min' = yesterday 23:30. '-1h' has been silently showing 'since yesterday 23:00' labeled as 'Last 1 hour'. Sub-day units now roll from now, matching the backend's relative_date_parse; calendar units keep their day anchoring. New test freezes time and locks both behaviors; it fails without the fix (minute/second strings resolve to null) and the 39 pre-existing cases pin calendar-unit behavior unchanged. Generated-By: PostHog Code
|
Reviews (1): Last reviewed commit: "fix(metrics): make minute/second date ra..." | Re-trigger Greptile |
🤖 CI report
|
| Root | Eager (shipped) | Δ vs base | Budget |
|---|---|---|---|
entry (logged-out pages, app bootstrap)src/index.tsx |
3.76 MiB · 695 files | 🔺 +68 B (+0.0%) | █████████░ 87.7% of 4.29 MiB |
authenticated shell (every logged-in page)src/scenes/AuthenticatedShell.tsx |
11.52 MiB · 2,937 files | 🔺 +68 B (+0.0%) | █████████░ 89.5% of 12.87 MiB |
🟢 node_modules/monaco-editor/ stays out of src/index.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/index.tsx
🟢 node_modules/monaco-editor/ stays out of src/scenes/AuthenticatedShell.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/scenes/AuthenticatedShell.tsx
Largest files eagerly shipped from src/index.tsx
| Size | File |
|---|---|
| 275.2 KiB | ../node_modules/.pnpm/posthog-js@1.396.5/node_modules/posthog-js/dist/rrweb.js |
| 266.9 KiB | ../node_modules/.pnpm/@posthog+icons@0.37.4_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js |
| 224.5 KiB | src/taxonomy/core-filter-definitions-by-group.json |
| 211.3 KiB | ../node_modules/.pnpm/posthog-js@1.396.5/node_modules/posthog-js/dist/module.js |
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 105.9 KiB | src/lib/api.ts |
| 69.7 KiB | src/products.tsx |
| 61.7 KiB | src/lib/lemon-ui/icons/icons.tsx |
| 57.2 KiB | src/lib/utils/eventUsageLogic.ts |
| 39.6 KiB | src/lib/KeaDevTools.tsx |
Largest files eagerly shipped from src/scenes/AuthenticatedShell.tsx
| Size | File |
|---|---|
| 458.3 KiB | ../node_modules/.pnpm/@posthog+brand@0.3.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/driving-hogzilla.mjs |
| 302.9 KiB | ../node_modules/.pnpm/@posthog+brand@0.3.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/coffee-run.mjs |
| 275.2 KiB | ../node_modules/.pnpm/posthog-js@1.396.5/node_modules/posthog-js/dist/rrweb.js |
| 266.9 KiB | ../node_modules/.pnpm/@posthog+icons@0.37.4_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js |
| 253.2 KiB | ../node_modules/.pnpm/@posthog+brand@0.3.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/chart-hog.mjs |
| 239.2 KiB | ../node_modules/.pnpm/@posthog+brand@0.3.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/x-ray.mjs |
| 224.5 KiB | src/taxonomy/core-filter-definitions-by-group.json |
| 211.6 KiB | ../node_modules/.pnpm/@posthog+brand@0.3.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/money.mjs |
| 211.3 KiB | ../node_modules/.pnpm/posthog-js@1.396.5/node_modules/posthog-js/dist/module.js |
| 185.9 KiB | ../node_modules/.pnpm/@posthog+brand@0.3.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/hogpatch.mjs |
Posted automatically by check-eager-graph · sizes are eager output bytes (shipped, post-tree-shake) from the esbuild metafile · part of #32479
✅ Dist folder size — 🟢 -365.99 MiB (-20.0%)
Total size of the built frontend/dist folder (all assets), compared against the base branch.
Total: 1464.55 MiB · 🟢 -365.99 MiB (-20.0%)
Problem
Picking Last 5 minutes or Last 30 minutes in the metrics viewer renders "No data" even when the metric has samples seconds old (verified: 5,070 rows in the window in ClickHouse while the UI showed nothing). Two stacked defects in
lib/utils/dateFilters:isStringDateRegexaccepts[hdwmqy]only, butdateOptionsMapdefinesM(minute) ands(second). The viewer's minute options emit-5M/-30M→ regex miss →dateStringToDayJsreturns null → the viewer'sresolveDatefalls back todayjs('-30M')(invalid) → the loader silently returns[].dateStringToDayJsanchors every relative date atstartOf('day'), so-30Mwould mean today 00:00 − 30 min = yesterday 23:30 — a ~24h window labeled "Last 30 minutes". This also means the working-1hoption has been querying since yesterday 23:00 while labeled "Last 1 hour".Changes
Mands(both already indateOptionsMapandcomponentsToDayJs— the regex was the only gap).hour/minute/second) anchor at now (rolling window), matching the backend'srelative_date_parse; calendar units (d/w/m/q/y) keepstartOf('day')anchoring so insights behavior is untouched.How did you test this code?
-30M/-5M/-1h/-45sresolve to exact rolling instants). Red without the fix (1 failed / 39 passed), green with it (40/40) — the 39 pre-existing cases pin calendar-unit anchoring unchanged.query-metrics— confirming data presence and isolating the bug to date resolution.🤖 Agent context
Autonomy: Human-driven (agent-assisted)