{"record":{"id":"76ccdfb44bed57d0","repo":"loco-rs/loco","slug":"implement-up-for-the-name-migration","errorCode":null,"errorMessage":"implement `up()` for the `{{name}}` migration","messagePattern":"implement `up\\(\\)` for the `(.+?)\\}` migration","errorType":"panic","errorClass":null,"httpStatus":null,"severity":"error","filePath":"loco-gen/src/templates/migration/empty.t","lineNumber":29,"sourceCode":"- into: \"migration/src/lib.rs\"\n  before: \"pub struct Migrator\"\n  content: \"mod {{module_name}};\"\n---\nuse sea_orm_migration::{prelude::*, schema::*};\n\n#[derive(DeriveMigrationName)]\npub struct Migration;\n\n#[async_trait::async_trait]\nimpl MigrationTrait for Migration {\n    async fn up(&self, m: &SchemaManager) -> Result<(), DbErr> {\n        // Loco could not infer a schema change from the name `{{name}}`, so this\n        // migration does nothing yet. Write the change here — the helpers in\n        // `loco_rs::schema` (`add_column`, `remove_column`, `rename_column`,\n        // `add_reference`, `create_table`, ...) cover the common cases — and\n        // give `down()` the inverse. Until then `db migrate` panics here rather\n        // than recording a migration that changed nothing.\n        todo!(\"implement `up()` for the `{{name}}` migration\")\n    }\n\n    async fn down(&self, m: &SchemaManager) -> Result<(), DbErr> {\n        Ok(())\n    }\n}\n\n","sourceCodeStart":11,"sourceCodeEnd":37,"githubUrl":"https://github.com/loco-rs/loco/blob/23639d1e360dbc618073642b507d6f8664adbaff/loco-gen/src/templates/migration/empty.t#L11-L37","documentation":"A panic raised by a `todo!()` in a freshly generated Loco migration. When the generator cannot infer a schema change from the migration name (e.g. `cargo loco generate migration AddPostsTable` is too ambiguous), it emits an empty migration whose `up()` panics with this message so that a no-op migration is never silently recorded in `_loco_migrations`.","triggerScenarios":"Running `cargo loco db migrate` (or anything that boots migrations) after generating a migration whose name the generator could not map to a schema change, without editing the `up()` body.","commonSituations":"Developers run `cargo loco generate migration` with a name that doesn't match Loco's naming conventions (e.g. `posts` instead of `CreatePosts`), then immediately run `db migrate`; CI pipelines fail on a migration stubbed earlier and forgotten.","solutions":["Open migration/src/m<timestamp>_<name>.rs and implement `up()` using `loco_rs::schema` helpers (create_table, add_column, remove_column, rename_column, add_reference)","Give `down()` the inverse operation so rollback works","Alternatively delete the unused generated migration file and regenerate with a conventional name (e.g. CreatePosts) that the generator can infer","Re-run `cargo loco db migrate`"],"exampleFix":"// before\nasync fn up(&self, _m: &SchemaManager) -> Result<(), DbErr> {\n    todo!(\"implement `up()` for the `AddPosts` migration\")\n}\n// after\nasync fn up(&self, m: &SchemaManager) -> Result<(), DbErr> {\n    m.create_table(\n        Table::create()\n            .table(Posts::Table)\n            .col(ColumnDef::new(Posts::Id).integer().primary_key())\n            .col(ColumnDef::new(Posts::Title).string().not_null())\n            .to_owned(),\n    ).await\n}","handlingStrategy":"validation","validationCode":"grep -rL \"todo!\" migration/src/ || echo \"some migrations are still stubs\"","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Always implement up()/down() immediately after `cargo loco generate migration`","Use conventional migration names (CreateX, AddXToY, RemoveXFromY) so the generator infers the schema change","Grep for `todo!` in migration/ as part of CI before running migrate"],"tags":["migration","panic","database","todo"],"backgroundTag":"missing-required-argument","analyzedSha":"23639d1e360dbc618073642b507d6f8664adbaff","analyzedAt":"2026-09-12T01:47:20.769Z","contentChangedAt":"2026-09-12T01:47:20.769Z","schemaVersion":2},"datasetVersion":"2026-09-16T04:17:20.429Z"}