cli: wheels seed --generate is non-functional — every model errors, zero rows created, reports success

[bpamiri]

Summary

The legacy random-data path documented in the seeding guide ("bypasses your seed files and generates random fake records for every model") creates nothing and claims success.

Repro (released 4.0.3, scratch app with Role/User/Post/Category models)

wheels seed --generate   # → 'Seeding completed.' exit 0 — but zero new rows
curl 'http://localhost:8080/wheels/cli?command=dbSeed&format=json&mode=generate&count=2'

Bridge JSON shows the truth:

{"success": true,
 "message": "Database seeding completed. Created 0 records across 5 models.",
 "SEEDED": [
  {"MODEL":"Category","SUCCESS":false,"ERROR":"there is no property with name [NAME]  found in [string]"},
  {"MODEL":"Post","SUCCESS":false,"ERROR":"No matching function [MODEL] found"},
  {"MODEL":"Role","SUCCESS":false,"ERROR":"No matching function [MODEL] found"}, ...]}

Root cause

Two bugs in vendor/wheels/public/views/cli.cfm (~910-975; develop carries the same loop, refactored but structurally identical — not behaviorally re-verified there):

1. The generate loop is broken — model(modelName) / $classData().properties fail in the cli.cfm view context ("No matching function [MODEL] found"; the one model that resolved choked iterating properties).
2. Failure is reported as success — the per-model catch appends success=false entries but overall result.success stays true and the CLI prints "Seeding completed." with exit 0. The fix(seed): fail and roll back when seedOnce entries fail validation #2987 honesty fix covered convention mode only; generate mode still lies.

Proposed direction (either)

• Fix the model-resolution context and make overall success false when any model entry fails; or
• Retire --generate outright (the seeding guide already calls it legacy and steers users to seedOnce()) — remove the flag, the cli.cfm branch, and the guide bullet together.

Acceptance

• wheels seed --generate either creates rows and exits 0, or errors loudly with non-zero exit, or no longer exists (flag + docs removed coherently).

Reported by the guide-behavioral-audit P1 batch 2 (work item p1-14-migrations, claim seed-10; wheels CLI 4.0.3 + Lucee 7 + SQLite).

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior backed by a repro: wheels seed --generate prints "Seeding completed." and exits 0 while creating zero rows, and the bridge JSON shows every model erroring (No matching function [MODEL] found, there is no property with name [NAME] found in [string]). Clear "what happened" + "what I expected" + reproduction.

Suspected layer

seed — the seeding/generate path. The defect lives in the CLI seed bridge view vendor/wheels/public/views/cli.cfm (~910-975), with the develop branch carrying the same loop refactored but structurally similar (per the reporter, not behaviorally re-verified there).

Fix sketch

Two coupled defects in the cli.cfm generate loop: (1) model resolution fails in the view context — model(modelName) / $classData().properties do not resolve (No matching function [MODEL] found); and (2) per-model failures are swallowed — the catch appends success=false entries but overall result.success stays true, so the CLI lies (the ##2987 honesty fix covered convention mode only, not generate mode). The fix is either (a) repair the model-resolution context and make overall success false when any model entry fails, or (b) retire --generate entirely — removing the flag, the cli.cfm branch, and the seeding-guide bullet together, since the guide already steers users to seedOnce().

Confidence: medium

The root cause is well-isolated and the target file is named, but the report itself offers two legitimate directions (fix vs retire the legacy flag) — a design trade-off rather than a single mechanical change — and the honest-success change touches the CLI success-reporting contract.

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

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #3107

Spec: vendor/wheels/tests/specs/seederSpec.cfc (generateSeeds() describe block) — failing → passing. Captured the failing state first (3 errors: No matching function [generateSeeds]), then green after implementation (core suite 4424 passed, 0 failed, 0 errors; seederSpec bundle 20 passed, 0 failed).

Implementation:

• vendor/wheels/Seeder.cfc — new generateSeeds(models, count) that iterates $classData().properties as the struct it is and reports honest overall success/message.
• vendor/wheels/public/views/cli.cfm — generate branch delegates to generateSeeds(); duplicated page-level generateTestData() removed.

Approach: I took the fix direction (rather than retiring --generate). The bug was two coupled defects — the loop iterated the property struct as if it were an array of property structs (prop.name → there is no property with name [NAME] found in [string]), and per-model failures were swallowed so the run reported success=true with zero rows. The new path makes the bridge return success=false on any failure, so parseCliResponse() throws Wheels.Cli.CommandFailed and the CLI exits non-zero instead of printing "Seeding completed."

A human review is required before merge. The Reviewer will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.