Fix NaN handling in file read limits

[pavankumar-vh]

Overview

Fix NaN handling in file read limits in common/src/util/file-read-limits.ts.

Bug Description

The function didn't validate that remainingChars and remainingTokens are finite numbers. If they were NaN or Infinity, Math.max(0, NaN) would return NaN, causing incorrect calculations.

Fix

Added Number.isFinite() checks 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/file-read-limits.ts - Added NaN validation

Scope

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

[codebuff-team]

Thanks for the contribution. The change itself is small and harmless: guarding remainingChars/remainingTokens with Number.isFinite before the Math.max calls is a reasonable defensive pattern, and it's correctly scoped to common/.

A few concerns before this is worth porting:

1. No evidence of the actual bug. The PR body describes the theoretical failure mode (Math.max(0, NaN) returning NaN) but doesn't show a call site where remainingChars/remainingTokens can actually be NaN or Infinity. If callers always pass valid numbers, this is defensive code with no real-world trigger, and the maintainers will want to know why it's needed.
2. Silently defaulting to 0 may be the wrong behavior for Infinity. If remainingTokens is legitimately Infinity (e.g. "no limit"), coercing it to 0 would incorrectly truncate everything instead of applying no limit. Treating NaN and Infinity the same way conflates two very different problems.
3. No test added. Given this is a pure bug-fix PR, a unit test exercising NaN/Infinity inputs would make the fix verifiable and prevent regression, and would also clarify intended behavior for the Infinity case.

If you can point to where invalid values originate (e.g., a division somewhere upstream producing NaN), that would strengthen the case, and fixing it at the source might be preferable to patching it here. As-is, this is the right instinct but needs a concrete justification and test coverage before it's ready to port.

[codebuff-team]

Marking this stale - there has been no activity here for 29 days. It will close in 7 days unless someone comments.

This is backlog upkeep, not a verdict on the pull request. A single comment keeps it open, and anything closed this way can be reopened.

[codebuff-team]

Closing this as stale - no activity since it was flagged 7 days ago. Reopen it any time if it is still relevant; that is not a hassle and we would rather have it open than lost.

_{Closed automatically by the community triage bot. If this is wrong, reopen the issue or reply and a maintainer will take another look.}