Skip to content

Release rc.9, migration isolation (apalis._sqlx_migrations), it's on main but unreleased #113

Description

@jim4067

The README on main documents migration tracking in apalis._sqlx_migrations via sqlx.toml, but the latest published crate (1.0.0-rc.8, sqlx 0.8) still migrates against the default public._sqlx_migrations.

Any app tracking its own migrations with sqlx (e.g. sqlx-cli) collides with setup() or whichever migrator runs second fails.

Repro

Our migrations run first sqlx database drop && sqlx database create && sqlx migrate run && cargo run returns

2026-09-13T17:06:08.170485Z  INFO heirloom_backend::app: Redis client configured
2026-09-13T17:06:08.171076Z  INFO sqlx::postgres::notice: relation "_sqlx_migrations" already exists, skipping

thread 'main' (677167) panicked at src/app.rs:105:10:
failed to run apalis migrations: Migrate(VersionMissing(20260513185704))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

When reversed, i.e own migrations are run last sqlx database drop && sqlx database create && cargo run && sqlx migrate run

error: migration 20220530084123 was previously applied but is missing in the resolved migrations

Suggested

Relase the rc containing the apalis._sqlx_migrations isolation (works when using the git crate i.e apalis-postgres = { git = "https://github.com/apalis-dev/apalis-postgres" }).

This should also align with what the Readme suggests, and also the wording concerning the pre-1 and how migrations happen could be made tighter and less vague. e.g does fresh mean an empty DB, or a DB without pre-v1.0 apalis history? It's ambiguous for anyone migrating an existing app database

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions