fix: confine all objects to the apalis schema (#86)

[tysen]

Fixes #86

Every object apalis creates now lives in the apalis schema:

• generate_ulid() is created as apalis.generate_ulid() with a pinned SET search_path = apalis, public, so its bare gen_random_bytes() call resolves whether pgcrypto is installed into apalis (fresh DBs) or already exists in public.
• pgcrypto is installed with SCHEMA apalis on fresh databases.
• The sqlx migrations table moves to apalis._sqlx_migrations via a new sqlx.toml (create-schemas + table-name), which requires sqlx 0.9. The first migration's CREATE SCHEMA is now IF NOT EXISTS to coexist with create-schemas.

Also bumps sqlx 0.8 -> 0.9 and remaps the runtime/TLS cargo features (0.9 removed the combined runtime-*-tls flags), regenerates the .sqlx offline cache, and updates deny.toml / cargo-vet exemptions for the new dependency tree.

BREAKING CHANGE: existing pre-1.0 deployments track migrations in public._sqlx_migrations; after this change sqlx looks in apalis._sqlx_migrations and will try to re-run every migration. Recreate the apalis schema (and drop public._sqlx_migrations) when upgrading.

[geofmureithi]

You cannot modify migrations directly since this would break for existing users.

…

On Thu, 4 Jun 2026 at 20:06, Ty Larrabee ***@***.***> wrote: @tysen <https://github.com/tysen> requested your review on: apalis-dev/apalis-postgres#89 <#89> fix: confine all objects to the apalis schema (#86 <#86>) as a code owner. — Reply to this email directly, view it on GitHub <#89?email_source=notifications&email_token=AWXVRGSFXRERSUV24OGY65346GUBZA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTENRTGQ4DAMZRG4YDJJTSMVQXG33OWBZGK5TJMV3V64TFOF2WK43UMVSKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#event-26348031704>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWXVRGQHYAYRKMMSXZ2XST346GUBZAVCNFSM6AAAAACZ2VLV5GVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMRWGM2DQMBTGE3TANA> . You are receiving this because your review was requested.Message ID: ***@***.***>

[tysen]

The accidental pollution of the public schema with generate_ulid and pgcrypto is unfortunate but mostly harmless. Creating and using _sqlx_migrations in public is a real problem that has bitten users many times (see apalis-dev/apalis#81, apalis-dev/apalis#177, apalis-dev/apalis#439, #64).

I think you have an opportunity with your impending 1.0 release to make a breaking change and clean this up - this PR does so. The 0.9 version of sqlx lets us easily configure _sqlx_migrations to live in apalis. It is fortuitous that sqlx has added this capability right around now!

We have to edit the first migration because of the missing IF NOT EXISTS - because we would be creating the apalis schema outside of (and before) the sqlx migrations, it would fail otherwise.

We can't use an sqlx migration to move _sqlx_migrations into the apalis schema because sqlx creates and reads that table at the start of Migrator::run, before any migration in the set executes — so a migration can never relocate the table that's tracking it (it would run too late, and against the freshly-created table in the new location). Instead, PostgresStorage::setup() does the one-time move, relocating an existing public._sqlx_migrations into apalis and re-stamping the one edited migration's checksum, before handing off to the migrator. I believe this will work for new and existing users.

[geofmureithi]

Hey @tysen

Fresh installs via sqlx-cli already work, it reads sqlx.toml (create-schemas + table-name),

Have you run your fixes via sqlx migrate run? I tried and got some errors:

sqlx migrate run
Found `sqlx.toml` in current directory; reading...
error: while executing migration 20220530084123: error returned from database: function "notify_new_jobs" already exists with same argument types at line 374

[geofmureithi]

@tysen After playing around with the PR I think most of the code is ok.

I recommend we dont include the relocation functions.

I suggest we let the migrations fail and the user to manually upgrade their database. The docs would highlight that the manual update is needed:

When a user encounters:

called `Result::unwrap()` on an `Err` value: Migrate(VersionMismatch(20220530084123))

They can manually call:

ALTER TABLE public._sqlx_migrations SET SCHEMA apalis;

UPDATE apalis._sqlx_migrations SET checksum = ... WHERE version = 20220530084123;

Since this needs to be run once, it would be part of docs (Upgrading to V1) and not included in the code.

I need to take one more look and try out on several existing databases but those are my two cents.

Let me know your thoughts

[tysen]

That sounds like a good idea to me. I've updated the code.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!