Files
summercms/.planning/todos/pending/lagoon-readme-after-commit-callback-order.md
Jakub Zych 3f9d3b4f11 docs: sync todos with g15office and map phases to milestone tasks
Tag the 17 open todos with their g15office task IDs, close 7 todos that
are already done or promoted to Phase 16.3, and record the sync rules
and the phase-to-task map in .planning/G15OFFICE.md.
2026-10-11 02:01:50 +02:00

14 lines
1.5 KiB
Markdown

---
title: lagoon README registers an after-commit GORM callback that can sort after the flush
date: 2026-09-30
priority: high
area: summercms.go lagoon
g15office: fqfoclxq
---
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.