Fix NaN handling in windowDays calculation

[pavankumar-vh]

Overview

Fix NaN handling in windowDays calculation in common/src/util/freebuff-usage-summary.ts.

Bug Description

The function didn't validate that params.windowDays is a finite number. If it was NaN or Infinity, Math.max(1, NaN) would return NaN.

Fix

Added Number.isFinite() check to default to FREEBUFF_USAGE_MAP_DAYS for invalid numbers.

Testing

No existing tests for this function, but the fix prevents incorrect behavior with invalid inputs.

Files Changed

• common/src/util/freebuff-usage-summary.ts - Added NaN validation

Scope

This change only touches common/ which is an approved contribution area per the Contributing Guide.

[codebuff-team]

Good catch and a clean, minimal fix. The original Math.max(1, params.windowDays ?? FREEBUFF_USAGE_MAP_DAYS) indeed produces NaN if a caller passes NaN (or -Infinity), since ?? only falls back on null/undefined. Your Number.isFinite check correctly closes that gap, and common/ is within the accepted contribution scope per the guide.

A few things a maintainer will likely want before porting:

1. Style nit: the ternary line is quite long and mixes an explicit undefined check with Number.isFinite. Since Number.isFinite(undefined) is false already, you can simplify to Number.isFinite(params.windowDays) ? params.windowDays : FREEBUFF_USAGE_MAP_DAYS (drop the !== undefined check) — Number.isFinite returns false for undefined too, so the extra check is redundant.
2. No test was added. This is a pure function with a clear input/output contract (buildFreebuffUsageSummary), so a unit test covering NaN, Infinity, and undefined inputs would make this much easier to verify and port safely. The repo likely expects at least one test for a bugfix like this.
3. Minor naming: safeWindowDays is fine, but consider naming to reflect intent (normalizedWindowDays).

Overall the logic is sound and the change is small and focused — worth a maintainer's time once a test is added.