`wheels reload` reports "Application reloaded successfully." when the HTTP reload request fails (4xx/5xx)

[bpamiri]

Summary

wheels reload (cli/lucli/Module.cfc::reload()) prints Application reloaded successfully. based solely on makeHttpRequest() not throwing — it never inspects the HTTP status code. Against an Adobe app where ?reload=true currently 500s (the #3036 local.url shadowing regression, #3053), the CLI claims success while the app was never reloaded. The same blindness silently masks wrong-password responses (the framework serves a normal non-reloading page that the CLI ignores).

Repro (released 4.0.3 brew CLI against a develop @ f668c50 app on the adobe2023 harness)

wheels reload --password=smokepw
# -> Application reloaded successfully.
# -> Note: onApplicationStart does NOT re-fire. ...

curl -s -o /dev/null -w '%{http_code}\n' 'http://localhost:61753/?reload=true&password=smokepw'
# -> 500

Meanwhile the app's onApplicationStart counters (a writeLog in config/services.cfm, a CONFIG-RAN log in a controller config()) are unchanged across the CLI call — no reload happened.

Root cause

reload() in cli/lucli/Module.cfc treats any completed HTTP exchange as success; there is no status-code check and no verification that the application actually restarted.

Proposed direction

• Inspect the response status from makeHttpRequest: treat >= 400 (and connection-level failures) as errors — print the status plus a hint, exit non-zero.
• Optionally verify the reload took effect (e.g. compare /wheels/info?format=json uptime/instance id before and after, in development).
• Keep success-path output unchanged on Lucee.

Acceptance

• wheels reload exits non-zero with a clear message when the reload endpoint returns 4xx/5xx or the connection fails.
• CLI spec covering the failure path (stub server returning 500).
• Success path output unchanged on Lucee 7.

Reported by the 2026-06-11 guide behavioral audit (P1 batch 1): request-lifecycle verifier (claim reload-cli-command, code-broken — the Adobe 500 itself is tracked as #3053; this issue is the CLI's false-success reporting). Findings catalog: docs/superpowers/audits/2026-06-guide-audit-findings.md.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear "what happened / what I expected": wheels reload prints Application reloaded successfully. even when the reload endpoint returns 500, masking both the #3053 Adobe regression and wrong-password responses.

Suspected layer

cli — see cli/CLAUDE.md for canonical patterns. Concretely cli/lucli/Module.cfc.

Fix sketch

Root cause confirmed: makeHttpRequest() (cli/lucli/Module.cfc:6493) already reads conn.getResponseCode() (line 6500) but returns only the body string, discarding the status. reload() (line 807, request at line 838) therefore treats any completed exchange as success and unconditionally prints the green success line. The fix surfaces the HTTP status to the caller — either by changing the shared makeHttpRequest return shape (status + body) or adding a status-aware variant — then in reload() treats >= 400 (and connection-level failures) as an error: print the status with a hint and exit non-zero. The success-path output on Lucee stays unchanged. Optionally verify the reload took effect via a /wheels/info instance/uptime comparison.

Confidence: medium

The report and root cause are unambiguous, but the fix has a design trade-off: makeHttpRequest is a shared private helper with ~12 call sites, so surfacing the status without disturbing the other callers requires a deliberate choice (change return shape vs. add a variant) rather than a mechanical one-liner.