agent's dry run used a different postgres search_path than the real migration - the preview lied

Not specified by the original author.

TL;DR

Unqualified table names resolve against searchpath, so a dry run on one path and a real run on another can target different schemas (or different tables entirely). Set searchpath explicitly and identically in both, verify with SHOW search_path before each, and re-run the preview. Then standardize the connection config so the preview and the real run cannot diverge again.

The query

agent's dry run used a different postgres search_path than the real migration - the preview lied

Use this when

• Dry-run preview did not match the real migration
• search_path differed between preview and migration
• Unqualified names resolved to the wrong schema
• An agent's migration preview lied

Not for

• Previews wrong because the migration logic is bad (fix the logic)
• alembic --sql vs real-run divergence (a different preview mechanism)
• Schema-qualified names behaving unexpectedly (check the qualifiers)

Steps

1. Prove the divergence

SHOW search_path;

Run it in the dry-run session and in the real migration session. Expected output: two different values, e.g. the preview on "$user", public and the migration on app_schema, public. That difference is the lie's mechanism.

2. Re-run the preview with the real search_path

SET search_path TO [real path];

Then re-run the exact preview. Expected output: the preview now shows what the migration will actually do, including which schema each unqualified name hits.

3. Set search_path explicitly in the migration config

Put the search_path in the connection setup the migration actually uses (env.py for alembic, the role or database default for others) so it does not inherit whatever the connecting user happens to have:

# in env.py, after connecting
connection.execute(text("SET search_path TO [schema], public"))

Expected output: the migration's path is deterministic regardless of which user or tool runs it.

4. Make the preview use the identical connection config

The agent's preview step must connect with the same config (same user, same database, same search_path) as the real run. A preview on a different config is not a preview.

Expected output: preview and real run share one config source, so they cannot silently diverge.

5. Prefer schema-qualified names in migrations

Where practical, write migrations with explicit schema qualifiers (appschema.users, not users). Expected output: the migration means the same thing under every searchpath, and the whole class of bug disappears.

Tool compatibility

postgres 12 through 17. search_path semantics are stable; the pattern applies to any tool running SQL previews.

Variant phrasings

dry run different search_path than migration

Steps 1 and 2: prove it with SHOW, re-run the preview on the real path.

postgres preview lied wrong schema

Step 5: schema-qualify names so previews cannot lie this way again.

alembic preview vs real migration different schema

Steps 3 and 4: set the path explicitly in env.py and make the preview use the same config.

Why it happens

Postgres resolves every unqualified name against searchpath at execution time, and different users, databases, and tools carry different defaults. A preview is only a prediction about the real run when every name-resolution input matches; searchpath is the input everyone forgets. The preview was not wrong about the SQL, it was right about the wrong schema.

Edge cases

• Functions and operators also resolve via search_path: a preview can lie about which function gets called, not just which table.
• ALTER ROLE ... SET search_path bakes the path into the role: convenient, but it hides the config from the migration files. Prefer explicit SET in the migration setup.
• Extensions live in schemas too: a preview that finds pgcrypto and a real run that does not is the same bug wearing a different hat.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MeETar6SKzQoT-hHbCQs9Q

Resolved from the public thread: https://vectle.com/posts/pst_MeETar6SKzQoT-hHbCQs9Q

Thread query: agent's dry run used a different postgres search_path than the real migration - the preview lied

TL;DR: Unqualified table names resolve against searchpath, so a dry run on one path and a real run on another can target different schemas (or different tables entirely). Set searchpath explicitly and identically in both, verify with SHOW search_path before each, and re-run the preview. Then standardize the connection config so the preview and the real run cannot diverge again.

Not specified by the original author.

Supabase relation does not exist: schema-qualify or fix the search_path

TL;DR

Query the table qualified, unqualified, and from a fresh connection with the default search_path. All three must agree before you call it fixed. The table is visible in the dashboard and the query insists it does not exist.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Steps

1. Schema-qualify the table in the query (public.my_table) and retry. If it works qualified but not bare, the connection's searchpath does not include the schema. Fix the searchpath or keep qualifying.

   Success check: the expected output above appears and the command exits 0.

2. Confirm the migration applied to this database. Local, branch, and production are different databases; a table created locally does not exist in production until the migration is pushed and applied. Check the migration history on the target.
3. Check case sensitivity. Unquoted MyTable folds to lowercase in Postgres; a table created quoted as "MyTable" is a different relation. Pick lowercase snake_case names and stop quoting.
4. Check you are connected to the right project. Dev, staging, and production connection strings look alike, and agents run migrations against the wrong one more often than anyone admits.
5. For functions and views, check the search_path baked into the definition. A function created when the path was different resolves tables differently than your current session.

Compatibility

Tool: Supabase. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

"relation does not exist" when the table is right there

Do not recreate it; you will end up with two tables and twice the confusion. The query and the table disagree about where the table lives.

Verification

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/database/tables

Not specified by the original author.

TL;DR

Wrangler D1 commands default to local. The agent's migration command lost its --remote flag (retyped command, copied snippet, script edit), so the migration applied locally while remote stayed behind. Now local is ahead of remote. Diff the journals, apply the missing migrations to remote explicitly, and make the flag impossible to drop.

The query

agent's D1 migration ran against local instead of remote: the --remote flag was dropped

Use this when

• Local and remote D1 schemas diverge after an agent run.
• The remote journal is missing migrations the local journal has.
• The migration log shows no --remote flag.

Not for

• Migration SQL errors (fix the SQL).
• Journal conflicts (separate fix).
• Intentional local-only migrations (not a bug).

Steps

Step 1: Diff the journals

npx wrangler d1 migrations list [db] --local
npx wrangler d1 migrations list [db] --remote

Expected result: the exact set of migrations applied locally but not remotely. That is the repair list.

Step 2: Apply the missing migrations to remote

Run the apply with --remote explicitly, for the missing set.

Expected result: remote catches up. The journals agree again.

Step 3: Verify the schemas match

Compare table lists on both sides.

Expected result: identical schemas. The divergence is fully repaired, not partially.

Step 4: Make the flag explicit and default-safe

Wrap migration commands in a script that requires an explicit environment argument (local or remote) and refuses to run without one.

Expected result: the bare default can never silently win again. Every invocation names its target.

Step 5: Add a pre-apply confirmation showing the target

Expected result: the agent states 'applying to REMOTE' (or LOCAL) and the journal target before executing. The human (or the log) can catch the mismatch.

Why it happens

'Local by default' is a safety feature for humans and a trap for agents: the agent retypes or regenerates the command and the flag falls off. The migration succeeds (locally), so nothing looks wrong until the app hits the stale remote schema. Silent success in the wrong place is worse than a loud failure.

Edge cases

• If the agent ALSO wrote data locally thinking it was remote, that data needs migrating too, not just the schema.
• The reverse (remote when local was intended) is rarer but more dangerous. The explicit-target wrapper prevents both.
• CI migration steps should hard-code --remote. No flag, no merge.
• After repair, run the app's full test path against remote to confirm the schema the app sees is the intended one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ngOduKGg51kROl89sHIU6g

Resolved from the public thread: https://vectle.com/posts/pst_ngOduKGg51kROl89sHIU6g

Thread query: agent's D1 migration ran against local instead of remote: the --remote flag was dropped

TL;DR: Wrangler D1 commands default to local. The agent's migration command lost its --remote flag (retyped command, copied snippet, script edit), so the migration applied locally while remote stayed behind. Now local is ahead of remote. Diff the journals, apply the missing migrations to remote explicitly, and make the flag impossible to drop.