[Reputation Oracle] Squash migrations

[flopez7]

Issue tracking

#3347

Context behind the change

• All previous migrations have been deleted and a new squashed migration (InitialMigration) has been generated to reflect the current state of the database. That way we can simplify the migration history and make new deployments easier, while maintaining compatibility with already-migrated environments (production and staging).

How has this been tested?

• The squashed migration was deployed locally on a fresh database and verified to create all tables, indexes, enums, and constraints as expected.
• Functional tests were performed: user creation, login, and basic operations.
• The resulting schema was compared with the stg schema to ensure there are no structural differences.

Release plan

• IMPORTANT: Before deploying this squash, ensure that all previous migrations have been successfully applied in production and staging.
• For new environments, run the migrations as usual:
  yarn migration:run
• For production and staging, run the squashed migration in “fake” mode so it is registered as executed without applying any changes:
  yarn migration:run --fake

Potential risks; What to monitor; Rollback plan

Before running any STG/PROD migration, create a backup of the database in case any error happened. In case anything fails, restore the backup. (It is possible to create them inside Vercel dashboard)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

5 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
faucet-frontend	⬜️ Ignored (Inspect)			Jul 15, 2025 4:08pm
faucet-server	⬜️ Ignored (Inspect)			Jul 15, 2025 4:08pm
human-app	⬜️ Skipped (Inspect)			Jul 15, 2025 4:08pm
human-dashboard-frontend	⬜️ Skipped (Inspect)			Jul 15, 2025 4:08pm
staking-dashboard	⬜️ Skipped (Inspect)			Jul 15, 2025 4:08pm

[dnechay]

LGTM
Tested release plan steps on my existing local DB and got successful results

Please update yarn build yarn migration:run -> to just yarn migration:run in PR description

Few notes on the release plan:

• I suppose that migration might be run from local instead of changing back and forth pre-deploy command on render
• maybe once we apply new migration, we also cleanup history of migrations in public/migrations_typeorm table? or we going to keep it intentionally?

[flopez7]

Few notes on the release plan:

• I suppose that migration might be run from local instead of changing back and forth pre-deploy command on render

Yep, I just mentioned the commands to run locally. IMO we should run it that way instead of modifying render command

• maybe once we apply new migration, we also cleanup history of migrations in public/migrations_typeorm table? or we going to keep it intentionally?

I think it is good to have in that table all the history of what we have already deployed. I would just add the new migration without modifying the migration table.