fix(cli): reject non-finite numbers in settings editor - #29229
bunnysayzz wants to merge 1 commit into
Conversation
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 addresses a data corruption issue in the settings editor where overflow values were being accepted as valid input. By switching to a stricter finite number check, the application now prevents non-finite values from being processed, ensuring that the settings remain consistent and preventing serialization errors. 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
|
|
📊 PR Size: size/S
|
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request updates the parseEditedValue utility function in packages/cli to use !Number.isFinite(numParsed) instead of Number.isNaN(numParsed). This ensures that non-finite numeric values (such as Infinity, -Infinity, and overflow values like 1e309) are correctly rejected and treated as invalid (returning null), preventing potential serialization issues. Corresponding unit tests have been added to verify this behavior. I have no feedback to provide.
|
Hi there! Thank you for your interest in contributing to Gemini CLI. To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'. This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding. |
parseEditedValue('number', ...) only rejected NaN, so overflow input
like '1e309' parsed to Infinity, passed validation, and JSON
serialization silently stored it as null - corrupting the setting the
dialog had just accepted. Number.isFinite covers NaN and both
infinities; returning null makes the dialog keep the existing value.
Fixes google-gemini#29226
c595c36 to
aa5edaa
Compare
|
Rebased onto latest main (was 9 behind, clean, upstream never touched these files). This push should also retrigger the CLA check: I have now signed the Google CLA, so cla/google should flip green on this run. |
Fixes #29226.
parseEditedValue('number', ...)only rejectedNaN, so overflow input like1e309parsed toInfinity, passed validation, and JSON serialization silently stored it asnull— corrupting the setting the dialog had just accepted.Number.isFinitecoversNaNand both infinities; returningnullmakes the dialog keep the existing value (it already early-returns onnullinhandleEditCommit).Tests: new
parseEditedValue > numberblock (finite, empty, non-numeric, and the1e309/Infinity/-Infinityregression cases — the regression test fails pre-fix).settingsUtils.test.ts: 53 passed. eslint + prettier clean.