Skip to content

Conversation

@7ttp
Copy link
Contributor

@7ttp 7ttp commented Dec 30, 2025

when running supabase db push --include-seed, modified seed files were detected and their hashes updated, but the actual seed sql was not executed. this happened because ExecBatchWithCache only queued sql statements when Dirty was false, but modified seeds have Dirty set to true.

closes #4670

when a seed file is modified, the cli was only updating the hash in the
seed_files table but skipping the actual sql execution. this happened
because ExecBatchWithCache only queued sql statements when Dirty was
false, but modified seeds have Dirty set to true.
@7ttp 7ttp requested a review from a team as a code owner December 30, 2025 20:54
@mfairley
Copy link

@7ttp Could we get this landed soon?

@7ttp
Copy link
Contributor Author

7ttp commented Jan 16, 2026

@sweatybridge

@sweatybridge
Copy link
Contributor

This is intentional because most seed scripts are not idempotent. My suggestion would be to add a new seed file. Wdyt?

@mfairley
Copy link

This is intentional because most seed scripts are not idempotent. My suggestion would be to add a new seed file. Wdyt?

@sweatybridge The CLI prompts the user about updated seed files and then updates the hash for the file references stored in the database in supabse_migrations.seed_files. This seems to imply the files are run and it also informs the user prior to running them, so it's confusing if they aren't run.

Shouldn't it be the user's responsibility not to update a seed file if it's not idempotent? If I have to make new seed files then that feels no different to migrations.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

supabase db push --include-seed doesn't actually run seed files

3 participants