f7dfe68707
- lagoon.Validate reports numeric min failures with the max message - the lagoon README callback example sorts after the after-commit flush, and the pivot Preload ordering claim does not hold
1.4 KiB
title, date, priority, area
| title | date | priority | area |
|---|---|---|---|
| lagoon README registers an after-commit GORM callback that can sort after the flush | 2026-09-30 | high | summercms.go lagoon |
The lagoon.OnDatabase example in modules/lagoon/README.md registers its create callback with After("gorm:after_create") and calls lagoon.AfterCommit from it. GORM sorts that callback after lagoon:after_commit (itself After("gorm:commit_or_rollback_transaction")), so the work is buffered after the buffer was flushed and never runs, with no error or log. A docs test reproduced it: the same callback registered with After("gorm:create").Before("gorm:commit_or_rollback_transaction") runs as expected.
Found while writing docs/database/transactions.md (Phase 11.1 plan 04). The page registers the callback before GORM's commit callback and says why.
Suggested fix: change the README example to register before gorm:commit_or_rollback_transaction, and consider making lagoon.AfterCommit warn when it buffers work on a statement whose lagoon:after_commit callback has already run. The README was read-only in plan 11.1-04 (Phase 11 gap plan 11-08 owned it). While there, correct the lagoon.RegisterJoinTable comment and README line that say pivot reads use Preload(field) plus .Order(...) on the pivot's columns: GORM preloads many-to-many targets in a query without the join table, so ordering by a pivot column there fails with "missing FROM-clause entry"; an explicit join does work.