Repository navigation
fix(cli): validate finite numbers in numeric settings editor - #29968
DavidAPierce merged 3 commits into
Conversation
Update parseEditedValue to validate numeric values using Number.isFinite, preventing non-finite values from being serialized as null in settings storage. Closes google-gemini#29226
|
📊 PR Size: size/S
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request improves the robustness of the numeric settings editor by ensuring that only finite numbers are accepted. By switching from Number.isNaN to Number.isFinite, the application now correctly prevents non-finite values from being processed, maintaining data integrity for numeric settings and avoiding unexpected null values during serialization. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the parseEditedValue function in packages/cli/src/utils/settingsUtils.ts to reject non-finite numbers (such as NaN and ±Infinity) by replacing the Number.isNaN check with !Number.isFinite. This prevents serialization issues since JSON cannot represent non-finite numbers. Additionally, comprehensive unit tests have been added in packages/cli/src/utils/settingsUtils.test.ts to verify this behavior for both numeric and string settings. I have no feedback to provide as there are no review comments.
There was a problem hiding this comment.
Code Review
This pull request updates the parseEditedValue function in settingsUtils.ts to reject non-finite numbers (such as NaN and ±Infinity) by replacing the Number.isNaN check with !Number.isFinite. This prevents issues where non-finite numbers are persisted as null in JSON. Additionally, comprehensive unit tests have been added in settingsUtils.test.ts to verify this behavior for various numeric and non-numeric inputs. There are no review comments, and I have no additional feedback to provide.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the parseEditedValue function in settingsUtils.ts to use Number.isFinite instead of Number.isNaN. This change ensures that non-finite numbers, such as Infinity, -Infinity, and overflow values like 1e309, are rejected and returned as null, preventing issues with JSON serialization. Comprehensive unit tests have been added in settingsUtils.test.ts to verify this behavior for various numeric, non-finite, and non-numeric inputs, as well as to ensure string settings are unaffected. There are no review comments, and I have no additional feedback to provide.
Summary
Replace
Number.isNaNwithNumber.isFiniteinparseEditedValuewithinpackages/cli/src/utils/settingsUtils.tsso that non-finite values returnnullinstead of passing to the serializer.Details
Number.isNaNcheck acceptedInfinityand-Infinity,including numeric input that exceeds the double-precision range. JSON
serialization (
comment-json/JSON.stringify) writes non-finite numbersas
null, so these values replaced the stored setting withnull.Number.isFiniterejectsNaN,Infinity, and-Infinity. All finitevalues accepted before are still accepted.
SettingsDialogalready treats anullresult fromparseEditedValueasinvalid input and keeps the existing value, so no UI changes are needed.
numberbranch changes;string,array, andobjectparsing areuntouched. No breaking changes and no documentation updates.
Related Issues
Fixes #29226
Related to #29229 (earlier PR with the same approach)
How to Validate
Added unit test coverage in
packages/cli/src/utils/settingsUtils.test.tsverifying parsing of finite numbers, scientific notation, and rejection of
non-finite numbers and strings.
Run the settings utils tests:
Expected: 63 tests pass (49 existing + 14 new).
Run the
SettingsDialogtests (the only caller ofparseEditedValue):Expected: 64 tests pass with snapshots unchanged.
Run the full repository checks:
Edge cases covered by the new tests: integers, decimals, negative values,
scientific notation, surrounding whitespace, values beyond the double-precision
range,
Infinity,-Infinity,NaN, empty and whitespace-only input,non-numeric strings, and a
string-typed setting (unaffected by numericvalidation).
Pre-Merge Checklist