viable/strict/1788852547: Fix extract_scripts step-index zero-padding off-by-one (#187731)
PyTorch 的 extract_scripts.py 使用 enumerate(steps, start=1) 生成 1 到 len(steps) 的索引，但零填充宽度由 len(steps)-1 计算。当步骤数为 10 的幂时，最大索引需要多一位数字，导致文件名排序错误（如 1.sh, 10.sh, 2.sh）。修复改为使用 len(steps) 计算宽度，并添加测试 tools/test/test_extract_scripts.py 验证 10 步作业的前缀为两位数字。PR #187731 已合并。
Development
- First Reportviable/strict/1788852547: Fix extract_scripts step-index zero-padding off-by-one (#187731)PyTorch Core
- Industry Responsetrunk/1c9a207306db2d405aedde6ddc876d5148f6bd6c: Fix extract_scripts step-index zero-padding off-by-one (#187731)PyTorch Core
- Current Assessment此修复虽小，但反映了开源项目在维护工具链可靠性上的持续投入。对于 CI/CD 和自动化脚本，文件排序的确定性至关重要，此类 off-by-one 错误可能导致下游任务失败。PyTorch 作为广泛使用的框架，其工具链的稳定性对依赖它的开发者有间接影响。Agent Pulse · analysis
PyTorch 核心仓库修复了 extract_scripts.py 中的一个 off-by-one 错误。该脚本为每个提取的步骤生成带零填充前缀的文件名，但填充宽度基于 len(steps)-1 而非 len(steps)。当作业步骤数为 10 的幂时，最大索引（如 10）需要两位数字，而宽度计算为一位，导致文件名如 1.sh, 10.sh, 2.sh 排序混乱。修复将宽度计算改为 len(steps)，确保 10 步作业生成 01.sh 到 10.sh。新增测试 tools/test/test_extract_scripts.py 验证此行为，该测试在修复前失败，修复后通过。PR #187731 已合并。
此修复揭示了一个常见的边界条件错误：当使用零填充来保证字典序排序时，填充宽度必须基于最大可能索引，而不是索引范围的长度。对于 1-based 索引，最大索引等于元素数量，因此宽度应为 len(steps) 的位数。此修复通过添加针对 10 步作业的回归测试，确保此类边界情况不再被遗漏。
此修复虽小，但反映了开源项目在维护工具链可靠性上的持续投入。对于 CI/CD 和自动化脚本，文件排序的确定性至关重要，此类 off-by-one 错误可能导致下游任务失败。PyTorch 作为广泛使用的框架，其工具链的稳定性对依赖它的开发者有间接影响。
此修复提高了 PyTorch 工具链的可靠性，减少了因文件名排序错误导致的潜在构建问题。对于依赖 PyTorch 进行模型训练和部署的企业，这降低了 CI/CD 中断的风险，间接节省了开发时间。
此修复可能促使其他项目检查类似的索引填充逻辑。未来，PyTorch 可能进一步改进 extract_scripts 的测试覆盖，例如添加对 100 步等更大幂次情况的测试。