Affected version: Servy 7.9.0
In src/Servy.CLI/Validators/ServiceInstallValidator.cs:
if (!string.IsNullOrWhiteSpace(opts.MaxRestartAttempts)
&& (!int.TryParse(opts.MaxRestartAttempts, out var restart)
|| restart < AppConfig.MinMaxRestartAttempts
|| restart > AppConfig.MaxMaxRestartAttempts))
return CommandResult.Fail(Strings.Msg_InvalidMaxRestartAttempts);The three failure conditions (parse failure, below min, above max) share a single localized string Msg_InvalidMaxRestartAttempts that reads literally "Max Restart Attempts must be a number greater than or equal to 1". Passing e.g. --maxRestartAttempts=30000 returns an error saying the value must be >= 1 — but 30000 is >= 1. The real problem is it exceeds MaxMaxRestartAttempts (currently 100).
Reproduction:
servy-cli.exe install --name=Foo --path=C:\Windows\System32\notepad.exe ^
--enableHealth --recoveryAction=RestartService --maxRestartAttempts=30000
=> exits with code 1 and the "must be >= 1" message.
This wasted a meaningful amount of diagnostic time on our side because the message sent us down an integer-overflow rabbit hole instead of pointing at the actual range constraint.
Request: Use separate messages (e.g. Msg_MaxRestartAttempts_NotAnInteger, Msg_MaxRestartAttempts_BelowMin, Msg_MaxRestartAttempts_AboveMax) so diagnostics are actionable. Ideally also echo the accepted range in the message, e.g. "Max Restart Attempts must be between 1 and 100".
Same pattern likely applies to other numeric flags that share a single validation-error string — worth auditing all of them.
Affected version: Servy 7.9.0
In
src/Servy.CLI/Validators/ServiceInstallValidator.cs:The three failure conditions (parse failure, below min, above max) share a single localized string
Msg_InvalidMaxRestartAttemptsthat reads literally "Max Restart Attempts must be a number greater than or equal to 1". Passing e.g.--maxRestartAttempts=30000returns an error saying the value must be >= 1 — but 30000 is >= 1. The real problem is it exceedsMaxMaxRestartAttempts(currently 100).Reproduction:
=> exits with code 1 and the "must be >= 1" message.
This wasted a meaningful amount of diagnostic time on our side because the message sent us down an integer-overflow rabbit hole instead of pointing at the actual range constraint.
Request: Use separate messages (e.g.
Msg_MaxRestartAttempts_NotAnInteger,Msg_MaxRestartAttempts_BelowMin,Msg_MaxRestartAttempts_AboveMax) so diagnostics are actionable. Ideally also echo the accepted range in the message, e.g."Max Restart Attempts must be between 1 and 100".Same pattern likely applies to other numeric flags that share a single validation-error string — worth auditing all of them.