Fix NaN handling in build seconds calculation

[pavankumar-vh]

Overview

Fix NaN handling in build seconds calculation in common/src/util/db-health-alerts.ts.

Bug Description

The code didn't validate that buildSeconds is a finite number. If buildSeconds was NaN or Infinity, Math.round(NaN / 60) would return NaN.

Fix

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

Testing

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

Files Changed

• common/src/util/db-health-alerts.ts - Added NaN validation

Scope

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

[codebuff-team]

Thanks for digging into evaluateInvalidIndexes. Walking through the logic in common/src/util/db-health-alerts.ts though: the where message is only computed when !building || stuck is true. When building is true, that requires stuck to be true, which itself requires buildSeconds !== null && buildSeconds >= stuckMinutes * 60 - and a NaN comparison there is always false, so stuck can never be true when buildSeconds is NaN. So the NaN scenario described in the PR body can't actually reach the Math.round call as written.

There is a real (if narrow) edge case your fix does catch: if buildSeconds were Infinity (e.g. a malformed timestamp diff), the stuck comparison would pass (Infinity >= threshold is true), and the old code would print Math.round(Infinity / 60) = Infinity in the alert message, which is exactly the kind of malformed output you're trying to prevent. That's the actual justification worth citing.

Could you:

1. Update the PR description to describe the Infinity case rather than NaN, since that's the reachable path.
2. Add a small unit test exercising evaluateInvalidIndexes with an Infinity/NaN buildSeconds to lock in the behavior, since this file has no existing coverage for this function per your own testing note.

The change itself is small, safe, and in-scope for common/, but as submitted the rationale doesn't match the code path, which makes it hard to judge whether it's addressing a real production symptom or just speculative hardening.