Summary
`wheels migrate latest`, `wheels seed`, `wheels migrate info` all report success regardless of the framework's actual response. The HTTP call to `/wheels/cli?command=…` returns a JSON body with `success: false` and a specific error message; the CLI ignores both and prints a green check.
Repro (fresh-VM, brew-installed wheels 0.3.7 — pre-fix-wave)
```
$ wheels new blog && cd blog && wheels start
$ wheels migrate latest
Migration latest completed.
$ ls -la db/development.sqlite
-rw-r--r-- ... 0 bytes development.sqlite
$ curl -s 'http://localhost:8080/wheels/cli?command=info&format=json'
{"MESSAGES":"org.osgi.framework.BundleException: The OSGi Bundle with name [org.xerial.sqlite-jdbc] is not available locally...",
"success":false,
"wheelsVersion":"0.0.0-dev",
"datasource":"blog"}
```
The CLI saw a 200 with `success:false` and translated that into "Migration latest completed." The user has no way to know anything went wrong without manually probing the framework endpoint.
`wheels seed` is slightly better — it prints `Seeding failed: unknown error` — but "unknown" is not actionable when the framework returned a specific message.
Expected
When the framework returns `success: false`, the CLI should:
- Exit non-zero
- Print `MESSAGES` (or the relevant error payload) to stderr
- Distinguish "no migrations to run" (success:true, idempotent) from "migrations errored" (success:false)
Suggested fix
In the CLI HTTP wrapper (likely in `cli/lucli/Module.cfc` migrate/seed handlers), check the parsed JSON for `success === false` and reraise with the `MESSAGES` payload. Treat 200-with-success-false as a hard error.
Why this matters
This bug is the meta-bug that hid issue #1 (missing SQLite JDBC) for so long. Every fresh-VM tester saw a green check, then was confused when their app couldn't talk to the database. Fixing the silent-success path makes the next class of cliffs self-diagnosing.
Source
Surfaced in fresh-VM onboarding journal, 2026-04-25. See also the fixes already in `develop` (#2307, #2304) which address adjacent symptoms but not the underlying CLI swallowing.
Summary
`wheels migrate latest`, `wheels seed`, `wheels migrate info` all report success regardless of the framework's actual response. The HTTP call to `/wheels/cli?command=…` returns a JSON body with `success: false` and a specific error message; the CLI ignores both and prints a green check.
Repro (fresh-VM, brew-installed wheels 0.3.7 — pre-fix-wave)
```
$ wheels new blog && cd blog && wheels start
$ wheels migrate latest
Migration latest completed.
$ ls -la db/development.sqlite
-rw-r--r-- ... 0 bytes development.sqlite
$ curl -s 'http://localhost:8080/wheels/cli?command=info&format=json'
{"MESSAGES":"org.osgi.framework.BundleException: The OSGi Bundle with name [org.xerial.sqlite-jdbc] is not available locally...",
"success":false,
"wheelsVersion":"0.0.0-dev",
"datasource":"blog"}
```
The CLI saw a 200 with `success:false` and translated that into "Migration latest completed." The user has no way to know anything went wrong without manually probing the framework endpoint.
`wheels seed` is slightly better — it prints `Seeding failed: unknown error` — but "unknown" is not actionable when the framework returned a specific message.
Expected
When the framework returns `success: false`, the CLI should:
Suggested fix
In the CLI HTTP wrapper (likely in `cli/lucli/Module.cfc` migrate/seed handlers), check the parsed JSON for `success === false` and reraise with the `MESSAGES` payload. Treat 200-with-success-false as a hard error.
Why this matters
This bug is the meta-bug that hid issue #1 (missing SQLite JDBC) for so long. Every fresh-VM tester saw a green check, then was confused when their app couldn't talk to the database. Fixing the silent-success path makes the next class of cliffs self-diagnosing.
Source
Surfaced in fresh-VM onboarding journal, 2026-04-25. See also the fixes already in `develop` (#2307, #2304) which address adjacent symptoms but not the underlying CLI swallowing.