Problem
The hourly contributions endpoint reads days with Number(value) || 30 and uses it directly in date arithmetic. Negative values query a future date range, fractional values are silently accepted, and unbounded values such as Infinity or very large numbers make toISOString() throw, returning a 502 instead of a validation response.
Location
src/app/api/metrics/contributions/hourly/route.ts:20 (GET)
Evidence
days=-30 computes a future since date.days=1.5 is accepted even though the range is expressed in days.days=Infinity and sufficiently large values produce RangeError: Invalid time value before the GitHub request.- The main contributions, repos, and productive-hours endpoints already clamp equivalent parameters to
1..365.
Why this matters
The endpoint can generate incorrect GitHub search windows or fail with a server error for malformed client input. It also behaves inconsistently with the other metrics endpoints.
Suggested approach
Parse days as an integer, default invalid input to the existing 30-day range, and clamp valid input to 1..365 before computing the cache key and since date. Add route tests covering negative, fractional, zero, and unbounded values.
Requesting this be added to GSSoC - happy to work on it.
Problem
The hourly contributions endpoint reads
dayswithNumber(value) || 30and uses it directly in date arithmetic. Negative values query a future date range, fractional values are silently accepted, and unbounded values such asInfinityor very large numbers maketoISOString()throw, returning a 502 instead of a validation response.Location
src/app/api/metrics/contributions/hourly/route.ts:20(GET)Evidence
days=-30computes a futuresincedate.days=1.5is accepted even though the range is expressed in days.days=Infinityand sufficiently large values produceRangeError: Invalid time valuebefore the GitHub request.1..365.Why this matters
The endpoint can generate incorrect GitHub search windows or fail with a server error for malformed client input. It also behaves inconsistently with the other metrics endpoints.
Suggested approach
Parse
daysas an integer, default invalid input to the existing 30-day range, and clamp valid input to1..365before computing the cache key andsincedate. Add route tests covering negative, fractional, zero, and unbounded values.Requesting this be added to GSSoC - happy to work on it.