Repository navigation
[bug-fix] Fix oversized-number-crash: bound Python --number parsing - #5200
Draft
github-actions[bot] wants to merge 1 commit into
Draft
github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug fix — oversized-number-crash
Proposed fix for issue #5194, applying the
remediation from the bug assessment.
Verdict: valid · Severity: low
Summary
The Python extension branch-creation script now validates
--numberagainst a bounded integer domain before conversion, so oversized numeric inputs fail with a clear argument error instead of crashing atint().Changes
extensions/git/scripts/python/create_new_feature_branch.py0..2**63-1) for--numberand a defensive conversion guard with user-facing error text.tests/extensions/git/test_git_extension_python_parity.py--numberinputs; asserts no traceback on rejection.Tests Added or Updated
tests/extensions/git/test_git_extension_python_parity.py::TestCreateFeatureBranchParity::test_explicit_number_max_int64_accepted— verifies the maximum supported explicit number is accepted.tests/extensions/git/test_git_extension_python_parity.py::TestCreateFeatureBranchParity::test_explicit_number_above_max_int64_rejected— pins rejection for max+1 with expected error message.tests/extensions/git/test_git_extension_python_parity.py::TestCreateFeatureBranchParity::test_explicit_number_oversized_digits_rejected_without_traceback— verifies long digit strings are rejected cleanly without traceback.Local Verification
python3 extensions/git/scripts/python/create_new_feature_branch.py --json --dry-run --number 42 "some feature"→ pass (exit 0)python3 extensions/git/scripts/python/create_new_feature_branch.py --json --dry-run --number 9223372036854775808 "some feature"→ expected validation failure (exit 1, bounded-range error)python3 extensions/git/scripts/python/create_new_feature_branch.py --json --dry-run --number <5000-digit number> "some feature"→ expected validation failure (exit 1, bounded-range error, no traceback)python3 -m pytest ...could not run in this runner becausepytestis unavailable in the base Python environment.Deviations from Assessment
--numberhandling, rather than changing bash/powershell behavior in this fix-stage patch.Risks & Review Notes
--number; this PR intentionally scopes remediation to the Python crash path identified in the assessment.Refs #5194 · cc
@soarkit--numberand crashes atint()instead of rejecting it #5194