Nxtgauge Backend Services
3e701f2fe6
Some checks failed
build-and-release / build (ugc-content-creators) (push) Waiting to run
build-and-release / build (users) (push) Waiting to run
build-and-release / build (video-editors) (push) Waiting to run
build-and-release / build (catering-services) (push) Successful in 1m47s
build-and-release / build (companies) (push) Successful in 2m0s
build-and-release / build (cron) (push) Successful in 2m12s
build-and-release / build (customers) (push) Successful in 2m42s
build-and-release / build (gateway) (push) Successful in 1m0s
build-and-release / build (developers) (push) Successful in 1m27s
build-and-release / build (fitness-trainers) (push) Successful in 1m54s
build-and-release / build (employees) (push) Successful in 1m59s
build-and-release / build (job-seekers) (push) Successful in 1m57s
build-and-release / build (makeup-artists) (push) Successful in 1m39s
build-and-release / build (graphic-designers) (push) Has been cancelled
build-and-release / build (payments) (push) Has been cancelled
build-and-release / build (jobs) (push) Has been cancelled
build-and-release / build (social-media-managers) (push) Has been cancelled
build-and-release / build (tutors) (push) Has been cancelled
build-and-release / build (photographers) (push) Has been cancelled
Asked to review Tracecoin and AI implementation safety. Found and fixed two exploitable TOCTOU races, plus a data-integrity bug: 1. apps/payments/src/main.rs::verify_payment — the PayU success callback is called directly by the client (not a server-to-server webhook), so a user fully controls how many times they replay a valid success payload. The payment "is it still PENDING" check and the "mark SUCCESS + credit wallet" write were separate, non-transactional queries — concurrent replays could both pass the check before either commits, double- (or N-times-) crediting the wallet for one real payment. Now wrapped in a single transaction with `SELECT ... FOR UPDATE` on the payments row, so a second concurrent call blocks until the first commits, then correctly sees the row is no longer PENDING (Postgres re-evaluates the WHERE clause via EvalPlanQual after the lock is granted). 2. crates/db/src/models/ai/repository.rs — UserAiSubscriptionRepository had the exact same shape of bug: apps/users/src/ai/credits.rs:: charge_feature read the subscription, checked daily-limit and credit balance, THEN issued two separate unconditional `UPDATE ... SET x = x + $1` statements with no WHERE guard on the balance. N concurrent requests from one user all pass the check before any deduction lands, running up unlimited LLM API spend (this endpoint is called before/around real LiteLLM calls, so the cost is real). Added UserAiSubscriptionRepository::try_charge — a single conditional UPDATE that checks the daily limit and credit balance and deducts atomically, returning None (mapped to the existing error types) if either check fails. 3. apps/cron/src/tasks/auto_apply.rs — daily_actions_used was being incremented twice per auto-applied job (once in the credit-deduct UPDATE, once more in a second, redundant UPDATE right after) — silently halving job seekers' effective daily auto-apply limit. Removed the redundant second UPDATE. Also added non-negative CHECK constraints directly to the live database (tracecoin_wallets.balance/reserved, user_ai_subscriptions.daily_actions_used/monthly_credits_used/ purchased_credits_used) as defense in depth — belt-and-suspenders in case a future code path reintroduces a similar bug. |
||
|---|---|---|
| .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.