Fix --idle-timeout-seconds validation being skipped - #8009

Fixes #

No issue; this is a minor fix, so I did not open one first.

I was reading through parse in src/node/cli.ts and noticed that the lower bound
check for --idle-timeout-seconds sits above the block that resolves the value:

if (key === "idle-timeout-seconds" && Number(value) <= 60) {
  throw new Error("--idle-timeout-seconds must be greater than 60 seconds.")
}
...
// Might already have a value if it was the --long=value format.
if (typeof value === "undefined") {
  value = argv[i + 1] && !argv[i + 1].startsWith("-") ? argv[++i] : undefined
}

At that point value is only set for the --idle-timeout-seconds=<value> form. With the
space-separated form it is still undefined, Number(undefined) is NaN, and NaN <= 60
is false, so the check never fires. On main:

code-server --idle-timeout-seconds=30   -> error, as intended
code-server --idle-timeout-seconds 30   -> accepted, shuts down after 30 seconds

The config file goes through parse with --key=value and the
CODE_SERVER_IDLE_TIMEOUT_SECONDS branch has its own check, so both of those already
reject values of 60 or less. Only the space-separated flag slipped past.

The fix moves the same three lines below the value resolution, so both flag forms are
validated identically. I did not change the condition or the message.

I added a unit test to test/unit/node/cli.test.ts covering both forms plus an accepted
value. It fails on main on the space-separated case only:

● parser › should error if idle-timeout-seconds is too low
  Expected pattern: /--idle-timeout-seconds must be greater than 60 seconds/
  Received function did not throw
  > 275 |     expect(() => parse(["--idle-timeout-seconds", "60"])).toThrowError(

and passes with the change. The whole unit suite is green with it (23 suites, 343 tests).

Two things worth flagging, since you may see them differently than I do:

• This does change behaviour: --idle-timeout-seconds 30 used to be accepted and now
  errors out at startup. I took that as the point of the fix, since the same value is
  already rejected through the config file and the environment variable, but it will be
  visible to anyone who happened to rely on the flag form.
• I added an entry under the Unreleased section of the changelog, following what
  "Fix incorrect data path being used" (Fix incorrect data path being used #7991) did. Happy to drop it if you would rather
  keep the changelog for release-time edits.

AI tools used