[aborovsky]

No description provided.

[aborovsky]

What

• bright-cli repeater declares its own --timeout with a default of 30000 (ms). yargs also applied the global seconds-based --timeout coercion from CliBuilder to that default, so it became 30000000 ms (about 8h20m). Explicit values were not multiplied, only the default.
• The value is used as the Bright socket connect timeout (DefaultRepeaterServer) and as the target request timeout (RequestExecutorOptions).
• The reconnect warning Failed to connect to Bright cloud (attempt N) is logged when a reconnection attempt starts, not when it fails.

Why

A repeater lost its connection when the bridges-api pods restarted. socket.io started one reconnection attempt, and the WebSocket upgrade never got a response. With an 8h20m connect timeout, that attempt neither failed nor got retried for hours. The process stayed up, disconnected, with Failed to connect to Bright cloud (attempt 1) as its last log line.

How

• New Helpers.parseDuration(value, numericUnit): duration strings (10s, 1m) go through ms, and a plain number is read in the given unit.
• The global --timeout keeps seconds semantics: parseDuration(arg, 's').
• The repeater --timeout gets its own coercion: parseDuration(arg, 'ms'). Redeclaring an option's coerce replaces the global one in yargs, so the default stays at 30000 ms. Explicit values behave as before. Duration strings such as --timeout 1m now work; they used to become NaN because of number: true.
• The reconnect log now reads Reconnecting to Bright cloud (attempt N).

Tests

• Helpers.parseDuration: plain numbers, numeric strings and duration strings, for both units.
• RunRepeater.builder: runs through the real CliBuilder and checks that args.timeout, the socket connect timeout and the request timeout resolve to 30000 by default, 45000 for --timeout 45000, and 60000 for --timeout 1m. The test fails on the current code (30000000).
• ServerRepeaterLauncher.run: checks the new reconnect message.

With the built CLI against a local unreachable host, socket.io debug logging shows connect attempt will timeout after 30000 by default and 60000 with --timeout 1m.

Not in this PR

Each reconnect attempt is logged twice. socket.io's Manager emits reconnect_attempt, and DefaultRepeaterServer.scheduleReconnection also emits RECONNECT_ATTEMPT on connect_error with its own counter, so two reconnect mechanisms run side by side. This is left for a separate change.