36c555dc55
The most severe finding in this audit: `verifications` backs the entire
admin approval system this whole session's work depends on (every
role's profile submission, job posting, and requirement approval flow
goes through VerificationRepository). No active migration ever created
it, verification_logs, or approval_requests/approval_logs.
The correct schema for all of these already existed in
scripts/init-db.sql — a "complete schema" reference doc — but that file
is never actually executed by the real migration runner: Dockerfile.migrate
only COPYs crates/db/migrations into the image, and crates/db-migrate's
main.rs only ever reads that directory. init-db.sql has been dead
documentation this whole time, describing the schema this codebase
*should* have without any path to actually get there.
Cross-referencing init-db.sql against the Rust code that reads/writes
these tables found two bugs in init-db.sql itself:
- verification_logs.verification_request_id pointed at a separate,
unrelated `verification_requests` table instead of `verifications`
(already independently discovered and patched by an existing
migration, 20260718210823_fix_verification_logs_fk — this new
migration just creates it correctly from the start).
- approval_requests was missing UNIQUE(entity_type, entity_id), which
apps/users/src/handlers/verifications.rs's
`INSERT ... ON CONFLICT (entity_type, entity_id) DO UPDATE` requires.
Positioned before the earliest active migration that already assumed
these tables existed (20260718210823). The custom db-migrate runner
(crates/db-migrate) has no applied-migration tracking — it just re-runs
every *.up.sql file in filename order on every invocation — so there's
no "already applied, don't touch" risk from adding an earlier-dated
migration; idempotent IF NOT EXISTS guards make it safe regardless.
4 lines
152 B
SQL
4 lines
152 B
SQL
DROP TABLE IF EXISTS approval_logs;
|
|
DROP TABLE IF EXISTS approval_requests;
|
|
DROP TABLE IF EXISTS verification_logs;
|
|
DROP TABLE IF EXISTS verifications;
|