Repository navigation
[bug-fix] Fix oversized-number-crash: bound Python --number parsing - #5200
github-actions[bot] wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
The missing Git extension and catalog version bumps prevent existing installations from receiving the fix, while discarded normalization causes valid, heavily zero-padded branch numbers to be rejected.
2 open issues
What changed in this PR
This PR addresses #5194 by bounding explicit --number values in the Git extension’s Python branch-creation script, replacing oversized-input tracebacks with argument errors.
Changes:
- Validates explicit numbers against
0..2**63-1before conversion. - Adds defensive handling for conversion failures.
- Adds Python-only tests for the maximum, maximum plus one, and 5,000-digit inputs; Bash and PowerShell behavior remains unchanged.
| File | Description |
|---|---|
tests/extensions/git/test_git_extension_python_parity.py |
Adds boundary and oversized-input regression tests. |
extensions/git/scripts/python/create_new_feature_branch.py |
Adds bounded number validation and conversion-error handling. |
Review effort: Balanced (auto)
|
|
||
| SCRIPT_DIR = Path(__file__).resolve().parent | ||
| MAX_BRANCH_LENGTH = 244 # GitHub enforces a 244-byte limit on branch names | ||
| MAX_FEATURE_NUMBER = 2**63 - 1 |
There was a problem hiding this comment.
Fixed in commit 7bda569: the Git extension manifest and catalog are both bumped to 1.0.2.
Co-authored-by: mnriem <15701806+mnriem@users.noreply.github.com>
There was a problem hiding this comment.
🟢 Approval recommended
The crash path for oversized explicit feature numbers is addressed through bounded non-negative int64 parsing, defensive conversion handling, and targeted regression coverage.
1 resolved since last review
Review effort: Lite (auto)


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