Jakub Zych
3f9d3b4f11
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.
1.7 KiB
title, date, priority, area, g15office
| title | date | priority | area | g15office |
|---|---|---|---|---|
| make:model and make:migration in the same second produce migrations that run out of order | 2026-09-30 | high | summercms.go internal/build | xp2bt2rl |
nextMigrationFile in internal/build/artifact.go names a migration <UTC second>_<slug> and only moves to the next second when a file with the same full name already exists. Two migrations with different slugs created in the same second share one timestamp, and refreshRegistry sorts them by file name. Running summer make:model acme.news Item and summer make:migration acme.news AddFlag back to back (a probe in a copy of examples/hello, 2026-09-30) wrote 20260930213644_add_flag.go and 20260930213644_create_acme_news_items.go, and registry.gen.go listed AddFlag before CreateItems. gormigrate runs the set in slice order, so the ALTER TABLE migration would run before the CREATE TABLE one and fail.
Found while writing docs/setup/porting-a-plugin.md (Phase 11.1 plan 05). The page tells the developer to check updates/ and rename a clashing file, and docs/console/scaffolding.md was corrected: it had said that migrations created in the same second get consecutive timestamps.
Suggested fix: in nextMigrationFile, move to the next second while any file in updates/ already starts with the candidate timestamp (or with a later one), not only when the same name exists, so every new migration sorts after every existing one. Add a unit test that creates two differently named migrations with a frozen migrationNow. Update docs/console/scaffolding.md and the porting page's note in the same change (the D-13 docs rule). internal/build is outside the docs phase boundary, so it is not changed in Phase 11.1.