Commit f16304a
committed
workflows: validate CHUNK_INDEX / CHUNK_COUNT inputs explicitly
workflow_call's `type: number` is enforced at the YAML boundary
only; direct API or templated callers can send non-numeric strings
that end up in the env. Bash's arithmetic context silently treats
non-numeric as 0, so "abc" passed `-lt 1`, hit the silent reset
to 1, and the chunk slice ran with a quietly-wrong CHUNK_COUNT.
Add explicit guards before any numeric comparison:
1. Regex `^[0-9]+$` on both CHUNK_INDEX and CHUNK_COUNT — fail
with "is not a non-negative integer" naming the bad field.
2. Hard-fail CHUNK_COUNT < 1 (was: silent reset to 1) — masking
caller bugs is worse than failing loudly.
3. Existing CHUNK_INDEX >= CHUNK_COUNT range check unchanged.
Each failure mode emits a distinct error message so a misconfig
caller can tell format-error from range-error at a glance.1 parent d0e480b commit f16304a
1 file changed
Lines changed: 21 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
376 | 376 | | |
377 | 377 | | |
378 | 378 | | |
| 379 | + | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
| 386 | + | |
379 | 387 | | |
380 | 388 | | |
381 | | - | |
| 389 | + | |
| 390 | + | |
| 391 | + | |
| 392 | + | |
| 393 | + | |
| 394 | + | |
| 395 | + | |
| 396 | + | |
| 397 | + | |
| 398 | + | |
| 399 | + | |
| 400 | + | |
| 401 | + | |
382 | 402 | | |
383 | 403 | | |
384 | 404 | | |
| |||
0 commit comments