Nxtgauge Backend Services
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.
|
||
|---|---|---|
| .cargo | ||
| .forgejo | ||
| .gitea/workflows | ||
| .github/workflows | ||
| .mavis/plans | ||
| .sqlx | ||
| apps | ||
| crates | ||
| docs | ||
| load-tests | ||
| scripts | ||
| tests | ||
| .env.example | ||
| .env.test111 | ||
| .gitignore | ||
| cargo-deny.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| companies.pid | ||
| customers.pid | ||
| DEPLOYMENT_OPTIMIZATION.md | ||
| docker-compose.yml | ||
| Dockerfile.base | ||
| Dockerfile.fast | ||
| Dockerfile.from-binary | ||
| Dockerfile.migrate | ||
| Dockerfile.optimized | ||
| Dockerfile.simple | ||
| Dockerfile.superfast | ||
| Dockerfile.template | ||
| Dockerfile.ultrafast | ||
| Dockerfile.working | ||
| gateway.pid | ||
| job_seekers.pid | ||
| k8s-migration-job.yaml | ||
| README.md | ||
| start-services.pid | ||
| start-services.sh | ||
| TESTING_STRATEGY.md | ||
| users.pid | ||
| wir.md | ||
NXTGAUGE Backend Rust
Rust migration target for nxtgauge-nov-2025-backend, preserving the same microservices and request flow.
Target Service Topology
gateway(HTTP API)users(identity, runtime roles, onboarding, approvals)companiescustomersprofessionalsjobseekers
Migration Policy
- Keep contracts stable (REST + proto semantics).
- Keep runtime-config and onboarding schema behavior unchanged during parity phases.
- Replace service implementations one by one.
See docs/MIGRATION_MASTER_PLAN.md for full staged plan.
CI (Woodpecker)
Required secrets:
REGISTRY_USERNAMEREGISTRY_PASSWORD
See .forgejo/workflows/README.md for details.