Skip to content

Conversation

@Zangetsu101
Copy link
Contributor

@Zangetsu101 Zangetsu101 commented Nov 17, 2025

  • Introduce mongo foreign data wrapper to migrate legacy mongo data
    • This required a migration to be run as the "SUPERUSER" so a separate SUPERUSER postgres migration path was introduced
  • Migrate the legacy users to postgres via a feature flag migrate-legacy-users
  • Refactor the tRPC context to allow defining public procedures that don't require authentication. The v2 seed data endpoint needs this.
  • Remove legacy mongo migration status outputs and skip typecheck which reduced the migration service startup time by 66%.
  • The postgres migration files now get restored to their original state (i.e. without the environment variables being replaced) regardless of the migration passing or not

opencrvs/opencrvs-countryconfig#1172

@github-actions

This comment has been minimized.

@Zangetsu101 Zangetsu101 changed the title Ocrvs 10450 feat(ocrvs-10450): legacy user migration Nov 25, 2025
@Zangetsu101 Zangetsu101 marked this pull request as ready for review November 25, 2025 11:08
@Zangetsu101
Copy link
Contributor Author

Could this be elaborated? Sounds unsafe without context

Basically this would allow us to create endpoints that don't require auth only IF we want. Currently we do not have any yet but after the legacy users are removed, we will be deprecating the data-seeder package and define a public endpoint in events service that will seed data.

@ocrvs-bot
Copy link
Contributor

Your environment is deployed to https://ocrvs-10450.e2e-k8s.opencrvs.dev

@Zangetsu101
Copy link
Contributor Author

@makelicious I've put the legacy user migration under the migrate-legacy-users flag and we are running it as a separate service from countryconfig: https://github.com/opencrvs/opencrvs-countryconfig/pull/1172/files#diff-ba8e76e28deb79c9af80270674a0f04af642ba68d7b1c608ed5790db9cc6f4c8R949

This allows us to easily switch back to the official postgres image once the migrations have run successfully.

})

/** @knipignore */
export const publicProcedure = t.procedure
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially I planned on creating a public endpoint to run the migration but afterwards moved the migration to the "migration" package. Still retaining the public procedure as the seed endpoint would potentially need it after the refactor.

@@ -0,0 +1,43 @@
-- Up Migration
CREATE TYPE status_type AS ENUM(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I've been there too. Let's enforce it with zod schema then

);

CREATE TABLE users(
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, kinda forgot to add it in

async function setupPostgresServer() {
return new PostgreSqlContainer('postgres:17.6')
return new PostgreSqlContainer(
'docker.io/chumaky/postgres_mongo_fdw:17.6_fdw5.5.2'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We mainly need it for our legacy data migration on 2.0. Perhaps we can switch back to official images in 2.1 and remove these mongo related migration files. Do you see any constraints on going with that route?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually yes, they are dependent on the timestamps and I've also had to change the timestamps if newer migrations were merged into develop first. But that only applies if all the migrations are tracked using single migration table. I've created a separate one for the superuser ones:

--migrations-table="$migrations_table"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

formatting changes, can be ignored

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is basically a duplicate of the one defined in the events migration, to ensure the users table exists no matter which migrations run first, events or migrate-legacy-users.


GRANT SELECT, INSERT, UPDATE, DELETE ON users TO ${EVENTS_DB_USER};

ALTER TABLE users OWNER TO ${EVENTS_MIGRATION_USER};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing owner to the migration user as this runs as SUPERUSER

@naftis naftis self-requested a review December 9, 2025 09:10
Copy link
Contributor

@makelicious makelicious left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! You might get better review regarding .sh changes from someone else.

@Zangetsu101 Zangetsu101 merged commit 755e62f into develop Dec 10, 2025
123 of 124 checks passed
@Zangetsu101 Zangetsu101 deleted the ocrvs-10450 branch December 10, 2025 09:40
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.

4 participants