fix(replica): re-apply extra user schema grants after schema migration

[julianam-w]

Problem

Extra users scoped to a persistentSchemas schema were left with no USAGE on it — the configured grants silently never took effect.

The grants only ever ran in the restore's init script, filtered by JOIN pg_namespace n ON n.nspname = trim(s.name). For a persistentSchemas replica that filter matches nothing: dbt doesn't exist in the restored snapshot yet, it arrives later via the migration Job. And where the schema does exist in the snapshot, the operator drops it before the migration writes the canonical copy — DROP SCHEMA … CASCADE takes every grant on it, plus the schema-scoped pg_default_acl row behind ALTER DEFAULT PRIVILEGES … IN SCHEMA, and the migration then recreates it with --no-privileges.

Either path ends with the extra user unable to read the schema it was configured for, with nothing in the logs.

Fix

Re-apply the grants from the operator (per AGENTS.md: prefer the operator over job-side SQL), once redaction and the migration have settled and before the Service selector moves — so no client ever sees the restore ungranted.

• postgres::schema_read_grants (pure, testable), grant_schema_read_on, is_superuser_on, connectable_databases_on
• replica::reconcile_extra_user_grants, called from reconcile ahead of the switchover block

The init-script pass stays: it's the only pass for read-only restores, where the analytics credential holds pg_read_all_data rather than SUPERUSER and so can't grant on schemas it doesn't own. The operator step probes for that and skips — on a restore already locked read-only nothing has rewritten a schema since init, so init's grants stand.

Users with an empty schemas list are deliberately ungranted and stay that way.

Tests

Six unit tests: generated SQL, identifier quoting (role and schema names come from the CRD), read-only-ness of the grants, and the user-list gating.

New integration test tests/extra_user_grants.rs (+ matrix entry) — needs CI, doesn't run locally. It asserts, on the restore the migration wrote:

• USAGE on the migrated schema
• the scoped user can actually SELECT the migrated rows
• default privileges cover a table the analytics role creates after the migration (the pg_default_acl half)
• public stays ungranted, so the grant is still scoped to what was declared

Note

cargo check can't build this repo on Windows — reqwest::ClientBuilder::unix_socket, tokio::signal::unix, and two canopy/verification.rs test assertions. All pre-existing on main; those files are untouched here.

🤖 Generated with Claude Code