declarative: sync command always generates a migration for a trigger that does not change in any way

[tolgap]

Describe the bug
I'm using the pre-release version with the pgmq changes. The declarative generate now works correctly. The sync command also no longer crashes.

But when using sync without changing anything, always seems to try and generate a migration for a trigger that simply does not change at all.

To Reproduce
Steps to reproduce the behavior:

1. Run supabase db schema declarative generate --local
2. Run supabase db schema declarative sync
3. Observe that it tries to generate a migration for a trigger that already exists in the DB 1to1

Expected behavior

Given a migration file with:

# migrations/01_initial.sql
create trigger "trg_update_priority_scores"
before insert or update of visitors_total_count, start_date, background_images, priority_override_score
on "my_schema"."tournaments"
for each row
execute function "my_schema"."update_priority_scores"();

And a schema file:

# database/schema/my_schema/tables/tournaments.sql
CREATE TRIGGER trg_update_priority_scores
  BEFORE INSERT OR UPDATE OF visitors_total_count, start_date, background_images, priority_override_score ON my_schema.tournaments
  FOR EACH ROW
  EXECUTE FUNCTION my_schema.update_priority_scores();

I would have expected nothing to be generated.

But instead
The declarative commands generates only this migration:

# migrations/20260416140754_declarative_sync.sql
CREATE OR REPLACE TRIGGER trg_update_priority_scores BEFORE INSERT OR UPDATE OF visitors_total_count, start_date, background_images, priority_override_score ON my_schema.tournaments FOR EACH ROW EXECUTE FUNCTION my_schema.update_priority_scores();

When I

• apply this generated migration to my db
• rerun the sync command again
• it, again, generates a migration with the same exact trigger

Screenshots
If applicable, add screenshots to help explain your problem.

System information
Rerun the failing command with --create-ticket flag.

• Version of OS: MacOS 26.4.1
• Version of CLI: v2.91.2
• Version of Docker: v4.69.0
• Versions of services: [output from supabase services command]

   SERVICE IMAGE          | LOCAL                  | LINKED 
  ------------------------|------------------------|--------
   supabase/postgres      | 15.8.1.085             | -      
   supabase/gotrue        | v2.188.1               | -      
   postgrest/postgrest    | v14.8                  | -      
   supabase/realtime      | v2.82.0                | -      
   supabase/storage-api   | v1.48.28               | -      
   supabase/edge-runtime  | v1.73.3                | -      
   supabase/studio        | 2026.04.08-sha-205cbe7 | -      
   supabase/postgres-meta | v0.96.4                | -      
   supabase/logflare      | 1.37.1                 | -      
   supabase/supavisor     | 2.7.4                  | -      

[avallete]

Hey ! Thank's for reporting ! I will have a look.

That might be due to a missing normalization in the definition of the trigger 🤔
I'm curious, what happen if you replace your migrations/01_initial.sql definition with the one produced by the output (CREATE OR REPLACE TRIGGER trg_update_priority_scores BEFORE INSERT OR UPDATE OF visitors_total_count, start_date, background_images, priority_override_score ON my_schema.tournaments FOR EACH ROW EXECUTE FUNCTION my_schema.update_priority_scores();)

Does it still generate diff's ?

[tolgap]

Hey @avallete

If I replace the trigger in 01_initial.sql, and then run declarative generate and then declarative sync, it still generates the same exact trigger in the diff in a <timestamp>_declarative_sync.sql.

[avallete]

Hey there !

I've tried to reproduce with this MRE:

create schema if not exists my_schema;

create table if not exists my_schema.tournaments (
  id bigint generated always as identity primary key,
  visitors_total_count integer,
  start_date timestamptz,
  background_images jsonb,
  priority_override_score numeric
);

create or replace function my_schema.update_priority_scores()
returns trigger
language plpgsql
as $$
begin
  return new;
end;
$$;

create trigger trg_update_priority_scores
before insert or update of visitors_total_count, start_date, background_images, priority_override_score
on my_schema.tournaments
for each row
execute function my_schema.update_priority_scores();

But, doing so, I can't get the same issue. So I'm suspecting that something else causes this change to always appears.
What happen if you do npx supabase@latest db schema declarative sync --no-cache ? I'm thinking the issue could be due to some catalog caching persisting instead of being replaced.

[tolgap]

@avallete

I downloaded the latest supabase CLI (v2.92.1)

Here's the lines:

$> supabase db schema declarative generate --experimental --local
Creating shadow database...
Applying declarative schemas via pg-delta...
Applied 1625 statements in 1 round(s).
Declarative schema written to supabase/database

$> supabase db schema declarative sync --experimental --no-cache 
Creating shadow database...
Initialising schema...
Seeding globals from roles.sql...

<hundreds of lines of migrations applying>

Creating shadow database...
Applying declarative schemas via pg-delta...
Applied 1625 statements in 1 round(s).
Generated migration SQL:
CREATE OR REPLACE TRIGGER trg_update_priority_scores BEFORE INSERT OR UPDATE OF visitors_total_count, start_date, background_images, priority_override_score ON my_schema.tournaments FOR EACH ROW EXECUTE FUNCTION my_schema.update_priority_scores();
                                                                                                                                                                                                                                                                             
Enter a name for this migration (press Enter to keep 'declarative_sync')

So the --no-cache didn't help out.

[avallete]

Hey @tolgap!

Thanks for the answer. Sadly, I still can’t reproduce the issue with the MRE you shared. Would you be able to put together one that reproduces the bug and share it somewhere I can access?

Otherwise, would you mind sharing your full supabase/migrations and supabase/database folders so I can try to reproduce it on my end? If you’d prefer not to share it publicly, you can add me to a private repo and I’ll take a look.

[tolgap]

@avallete I cannot add you to our codebase. And I do not want to make any of our migrations/schema public. If possible, I could zip our supabase/ folder and email it to you? If you could (cryptically) provide me your email address.

Otherwise you can email me directly: <firstname> at <companyname without app suffix>.nl

PS: I've spent quite some time to create an MRE, but there are a LOT of migrations and tables. At some point, removing the clutter around it, the problem just stops happening but its definitely unrelated clutter. It would still be a gigantic MRE.

[avallete]

@avallete I cannot add you to our codebase. And I do not want to make any of our migrations/schema public. If possible, I could zip our supabase/ folder and email it to you? If you could (cryptically) provide me your email address.

Otherwise you can email me directly: <firstname> at <companyname without app suffix>.nl

PS: I've spent quite some time to create an MRE, but there are a LOT of migrations and tables. At some point, removing the clutter around it, the problem just stops happening but its definitely unrelated clutter. It would still be a gigantic MRE.

No worries about the MRE what you’re describing (the issue disappearing when removing seemingly unrelated parts) usually points to some subtle interaction, so having the full setup will actually help more.

Thanks for taking the time to dig into it, I've emailed you on your GitHub contact email 👍

[avallete]

Hey there !

Quick update, I've been able to reproduce and identify the root cause of the issue on my end. Working on a fix right now.

[tolgap]

That is great to hear @avallete . Thank you so much!