| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…ription
Get-BranchName's fallback assumed the pipeline yields at least one element:
$fallbackWords = ($result -split '-') | Where-Object { $_ } | ...
return [string]::Join('-', $fallbackWords)
ConvertTo-CleanBranchName blanks every non-[a-z0-9] character, so a
description written in any non-Latin script leaves nothing for the pipeline
to emit. It yields $null, [string]::Join throws ArgumentNullException, and
$ErrorActionPreference = 'Stop' makes that terminating — the script dies
with a .NET stack trace, empty stdout, exit 1.
Measured with all three twins installed in one project:
desc='добавить авторизацию'
bash rc=0 BRANCH_NAME='001-'
py rc=0 BRANCH_NAME='001-'
ps rc=1 Exception calling "Join" ...
Identical for 添加用户认证 and '!!! ??? ***'. This hits every PowerShell
user who phrases a feature in their own language.
Wrap the pipeline in @() so it stays an array; Join on an empty array
returns "", matching the twins. Verified the normal case is unchanged
('a-to-the-of' -> 'a-to-the', 'add user authentication' ->
'001-user-authentication'), and the file stays ASCII-only (0 non-ASCII
bytes) for tests/test_ps1_encoding.py.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Prevents PowerShell feature creation from crashing when descriptions contain no ASCII words, restoring parity with Bash and Python.
Changes:
| File | Description |
|---|---|
| scripts/powershell/create-new-feature.ps1 | Handles empty fallback word lists safely. |
| tests/test_create_new_feature_python_parity.py | Tests punctuation-only and non-Latin descriptions. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Problem
Get-BranchName's fallback branch assumes the pipeline yields at least one element:
ConvertTo-CleanBranchName does $Description.ToLower() -replace '[^a-z0-9\s]', ' ', which blanks every non-ASCII character. So a description written in any non-Latin script leaves nothing for the pipeline to emit:
The script dies with a .NET stack trace, empty stdout, exit 1.
Reproduction on current main (bf88c9f)
All three twins installed into one project, same args, same cwd:
desc = 'добавить авторизацию' bash rc=0 BRANCH_NAME='001-' py rc=0 BRANCH_NAME='001-' ps rc=1 Exception calling "Join" with "2" argument(s): "Value cannot be null. Parameter name: values"Identical for 添加用户认证 and '!!! ??? ***'. The bash and Python twins both return an empty suffix and succeed.
This hits every PowerShell user who phrases a feature in their own language — Cyrillic, Han, Kana, Arabic, Greek, Hebrew — plus punctuation-only and accent-only descriptions.
Fix
Wrap the pipeline in @() so it stays an array. Verified at the primitive level:
After the fix, the same three descriptions:
rc=0 {"BRANCH_NAME":"001-", ...} x3 rc=0 {"BRANCH_NAME":"001-user-authentication", ...} (normal case unchanged)No breaking change. The only inputs whose behaviour changes are ones that today raise and exit 1. The file stays ASCII-only (verified 0 non-ASCII bytes) so tests/test_ps1_encoding.py::test_ps1_file_is_ascii_only still passes.
Verification
Written with assistance from Claude Code. Bug found, reproduced, and verified by me on current main with real powershell.exe.