Summary
Two related problems with the global --request-timeout <seconds> flag:
1. Invalid values are silently dropped
parseRequestTimeoutFlag returns undefined for any non-numeric / zero / negative input. undefined means "flag not supplied", so the factory falls back to TESTSPRITE_REQUEST_TIMEOUT_MS or the 120s default. A natural typo like --request-timeout 30s (meaning "30 seconds") therefore runs the command with the default 120s deadline while the operator believes they set 30s — no error, no signal.
$ testsprite --request-timeout 30s project list # runs with 120s, exits normally
Every other validated flag in the CLI fails loudly on bad input — --page-size 0, --page-size 101, --output yaml, --type junk all exit 5 with a VALIDATION_ERROR. --request-timeout is the odd one out.
2. The parser is duplicated five times
The exact same parseRequestTimeoutFlag body is copy-pasted into auth.ts, project.ts, usage.ts, init.ts, and test.ts. Drift between copies would silently change timeout behaviour depending on which command you ran.
Suggested fix
Hoist a single parseRequestTimeoutFlag into src/lib/client-factory.ts (next to resolveRequestTimeoutMs and the REQUEST_TIMEOUT_* constants) and make the flag strict: a non-numeric / zero / negative value throws a typed VALIDATION_ERROR (exit 5). Positive out-of-range values keep flowing through to resolveRequestTimeoutMs, which already clamps to [1s, 600s]. The TESTSPRITE_REQUEST_TIMEOUT_MS env-var path stays lenient (a stray global env var should not hard-fail every command) — only the explicit per-invocation flag becomes strict.
I have a PR ready for this.
Summary
Two related problems with the global
--request-timeout <seconds>flag:1. Invalid values are silently dropped
parseRequestTimeoutFlagreturnsundefinedfor any non-numeric / zero / negative input.undefinedmeans "flag not supplied", so the factory falls back toTESTSPRITE_REQUEST_TIMEOUT_MSor the 120s default. A natural typo like--request-timeout 30s(meaning "30 seconds") therefore runs the command with the default 120s deadline while the operator believes they set 30s — no error, no signal.$ testsprite --request-timeout 30s project list # runs with 120s, exits normallyEvery other validated flag in the CLI fails loudly on bad input —
--page-size 0,--page-size 101,--output yaml,--type junkall exit 5 with aVALIDATION_ERROR.--request-timeoutis the odd one out.2. The parser is duplicated five times
The exact same
parseRequestTimeoutFlagbody is copy-pasted intoauth.ts,project.ts,usage.ts,init.ts, andtest.ts. Drift between copies would silently change timeout behaviour depending on which command you ran.Suggested fix
Hoist a single
parseRequestTimeoutFlagintosrc/lib/client-factory.ts(next toresolveRequestTimeoutMsand theREQUEST_TIMEOUT_*constants) and make the flag strict: a non-numeric / zero / negative value throws a typedVALIDATION_ERROR(exit 5). Positive out-of-range values keep flowing through toresolveRequestTimeoutMs, which already clamps to[1s, 600s]. TheTESTSPRITE_REQUEST_TIMEOUT_MSenv-var path stays lenient (a stray global env var should not hard-fail every command) — only the explicit per-invocation flag becomes strict.I have a PR ready for this.