Skip to content

Reconcile schema.sql With the Actual Applied Migrations #844

Description

@llinsss

Background:
backend-2fa/schema.sql and backend-2fa/migrations/002_create_base_tables.sql describe two incompatible schemas: schema.sql has tenant_id columns and a composite (tenant_id, user_id) primary key on user_two_factor, recovery_code_usage, and canary_accounts; the actual migration (and the SQL db.rs runs, e.g. INSERT ... ON CONFLICT (user_id)) assumes a single-column user_id primary key with no tenant_id column at all.

Problem:
A developer who runs schema.sql directly (as the file's name and position in the repo invite) ends up with a database that the real PostgresTwoFactorStore queries cannot work against, since multi-tenancy is actually implemented purely at the application layer via TenantScopedStore key-prefixing, not via a DB column.

What "done" looks like:

  • schema.sql is regenerated from (or replaced by a pointer to) the concatenated migrations so there is a single source of truth.
  • A comment or CI check prevents the two from drifting again.

Implementation guidelines:

  • Key files: backend-2fa/schema.sql, backend-2fa/migrations/.

PR must include:

  • Updated schema.sql matching migrations
  • CI check or doc note preventing future drift
  • cargo test passing

Metadata

Metadata

Labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions