Repository navigation
deploy: numeric --release value hangs ~75s with 'Operation timed out' even under --dry-run #3111
Description
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 outReproduced 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
Activity
wheels-bot commentedon Jun 12, 2026
Wheels Bot — Triage
Classified as bug.
The report describes observable wrong behavior with a clear "what happened / what I expected" split:
--dry-runmust never open a connection, yet a purely numeric--release=1hangs ~76s and dies withOperation timed outwhile--release=v1short-circuits correctly. Reproduced twice across independent sessions.Suspected layer
cli— see.ai/wheels/cli/andcli/CLAUDE.mdfor canonical patterns (deploy subsystem lives undercli/lucli/services/deploy/).Fix sketch
The flag parser at
cli/lucli/services/deploy/cli/DeployArgsParser.cfc(the--release/--versionarms, lines 30–44) simply stores the raw string intoopts.version, so the divergence is downstream in the boot/version-resolution path (likelyDeployAppCli/ aDeployMainCliversion handler). A numeric release string probably fails anisValid/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 thedryRunflag. The fix likely: (a) treat numeric release labels as opaque strings identical to alphanumeric ones, and/or (b) gate the remote-resolution branch behind adryRun == falsecheck so dry-run never connects regardless of the value shape.Confidence:
mediumThe 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 commentedon Jun 12, 2026
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.docs(web/guides): align deploy CLI reference with the shipped positio…
fix(cli): stop numeric --release values from defeating deploy --dry-r…