deploy: numeric --release value hangs ~75s with 'Operation timed out' even under --dry-run

[bpamiri]

Repro (released brew CLI 4.0.3, macOS)

mkdir scratch && cd scratch && wheels deploy init
wheels deploy app boot --release=v1 --dry-run   # instant: prints the dry-run docker run line
wheels deploy app boot --release=1 --dry-run    # hangs ~76s, then:
# [ERROR] Error: lucee.runtime.exp.NativeException: Operation timed out

Reproduced twice across independent verification sessions (timed at 1:16.52 wall in the latest run). A purely numeric release value appears to trigger a real SSH/connection attempt to the template's placeholder host (192.168.0.1) despite --dry-run, while any non-numeric value (v1, abc1234) short-circuits correctly.

Suspected area

Likely a type-coercion branch in cli/lucli/services/deploy/cli/DeployArgsParser.cfc (--release arm at lines 39-42) or in DeployAppCli's version handling — a numeric string may fail an isValid/len-style guard and fall into a "resolve version from remote" path that ignores the dry-run flag.

Expected

--dry-run must never open a connection; numeric release labels (build numbers are a natural choice) should behave identically to alphanumeric ones.

Dedupe: not covered by the existing deploy batch #3084–#3089, nor by #2956/#2957 (security/orchestration scopes), nor by docs PR #3102. Found during the P2 guide-behavioral-audit (p2-2-cliref, claim deploy-app-02).

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear "what happened / what I expected" split: --dry-run must never open a connection, yet a purely numeric --release=1 hangs ~76s and dies with Operation timed out while --release=v1 short-circuits correctly. Reproduced twice across independent sessions.

Suspected layer

cli — see .ai/wheels/cli/ and cli/CLAUDE.md for canonical patterns (deploy subsystem lives under cli/lucli/services/deploy/).

Fix sketch

The flag parser at cli/lucli/services/deploy/cli/DeployArgsParser.cfc (the --release/--version arms, lines 30–44) simply stores the raw string into opts.version, so the divergence is downstream in the boot/version-resolution path (likely DeployAppCli / a DeployMainCli version handler). A numeric release string probably fails an isValid/len-style guard and falls into a "resolve version from remote" branch that opens an SSH/connection attempt to the template's placeholder host (192.168.0.1) without first checking the dryRun flag. The fix likely: (a) treat numeric release labels as opaque strings identical to alphanumeric ones, and/or (b) gate the remote-resolution branch behind a dryRun == false check so dry-run never connects regardless of the value shape.

Confidence: medium

The report and fix shape are clear, but this touches the deploy subsystem, so the auto-downgrade rule caps confidence at medium; the exact remote-resolution branch needs locating in propose-fix.

<!-- wheels-bot:triage:3111 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (cli/lucli/services/deploy/** / wheels deploy) and the bot's safety net requires a human in the loop before any code is written.