mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 10:25:06 +03:00
Jordi EnricandClaude Opus 4.8
ceff7b99bf
## Problem The per-service logs pages (e.g. `/project/[ref]/logs/auth-logs`) crashed with `RangeError: Invalid time value` (Sentry issue 7580074952). `calcChartStart` guarded `iso_timestamp_start` only against falsy values, so a truthy-but-unparseable timestamp (a malformed value in the URL query params) produced an Invalid Date, which propagated through `.add()` and threw when `startOffset.toISOString()` was called. The bug is on the legacy (non-OTEL) chart query path. The OTEL bucket helper had the same unguarded pattern; it did not crash but could skew the chart bucket size. ## Fix Validate parsed timestamps with `dayjs().isValid()` and fall back to now, matching the existing empty-param behavior. Applied to both `calcChartStart` (legacy) and `otelChartTruncFn` (OTEL). - Valid params produce identical output (existing tests unaffected) - Empty params still fall back to now - Malformed input no longer throws Added regression tests to `Logs.utils.test.ts` and `Logs.utils.otel.test.ts`. ## How to test - Run the logs unit tests: `pnpm test:studio` (or target `Logs.utils.test.ts` and `Logs.utils.otel.test.ts`) - In the dashboard, open a service logs page with a malformed timestamp in the URL, e.g. `/project/<ref>/logs/auth-logs?its=not-a-date` - Expected result: the page renders without crashing and the chart falls back to the default (now-based) time range <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved log chart time-range handling by safely resolving missing or invalid ISO timestamps via a shared timestamp resolver. * Updated chart bucketing and timestamp conflict logic to use the resolved endpoints, preventing errors and ensuring correct fallback granularity (including minute-level bucketing when needed). * **Tests** * Added regression coverage to confirm chart query generation (including OTEL queries) does not throw for unparseable start/end timestamps. * Verified fallback behavior to minute-level bucketing and non-throwing behavior for timestamp conflict handling. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>