Seeder reports success and commits when individual seedOnce() entries failed

[bpamiri]

Problem

vendor/wheels/Seeder.cfc:97 returns success=true ("Seeding complete") even when seedOnce() recorded action='failed' results (:193-199); failures are not counted and the wrapping transaction commits around them.

Impact

Silent fail-quiet on a data boundary: a seed file that half-applied looks identical to one that fully applied — in CI and in wheels seed output.

Suggested approach

Count failed results; surface them in the summary; return success=false (and a non-zero CLI exit via the existing typed-throw convention) when any entry failed. Decide explicitly whether failures should roll back the transaction or commit-with-report — document the choice.

Acceptance criteria

• A failing seedOnce() entry makes wheels seed exit non-zero with the failed entries named.
• Spec covering the partial-failure path.

Source

Internal framework review 2026-06-09; coverage audit 2026-06-10 (should-track item).

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior at vendor/wheels/Seeder.cfc:97: returns success=true ("Seeding complete") even when seedOnce() recorded action='failed' results at :193-199. The wrapping transaction commits around the failures and the CLI exits zero — a fail-quiet on a data boundary.

Suspected layer

seed — the Seeder.cfc seed() and seedOnce() methods. No .ai/wheels/seed/ reference doc exists today; canonical seed conventions live in CLAUDE.md § "Seeding" and in the file itself.

Fix sketch

Single-file change in vendor/wheels/Seeder.cfc: add a totalFailed counter, increment it in the failure branch at :191-197, include it in the summary message and final return struct at :96-103, and return success = false when totalFailed > 0. CLI exit-code propagation already exists via the typed-throw convention used elsewhere — cli/lucli/Module.cfc's seed command needs to detect the new success=false and exit non-zero (likely via the existing Wheels.Seeder.* throw pattern, or a new Wheels.Seeder.PartialFailure type). One design choice the issue flags explicitly: failures could either roll back the whole transaction or commit-with-report — the chosen behavior must be documented in the function docblock.

Confidence: medium

The bug, layer, and target file are unambiguous, but the issue body explicitly calls out a rollback-vs-commit-with-report design decision that needs to be made before the fix shape is final.

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

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2984

Spec: vendor/wheels/tests/specs/seederSpec.cfc (+ fixture vendor/wheels/tests/_assets/seeder/withfailure/seeds.cfm) — failing → passing
Implementation: vendor/wheels/Seeder.cfc, vendor/wheels/public/views/cli.cfm

Resolved the rollback-vs-commit-with-report design choice flagged in triage as rollback — documented in the runSeeds() docblock. Rationale: the wrapping transaction already signalled intent for atomicity, "half-applied" is the bug being fixed, and seedOnce() is idempotent so the caller can fix the offending entry and re-run safely.

Local run against Lucee 7 + SQLite went from 4255 pass / 1 fail / 1 error (the two new specs failing as designed before the fix) to 4257 pass / 0 fail / 0 error after the fix.

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