14014cb784
* Initial plan * Fix onLimitReached deprecation in rate-limit middleware - Replace deprecated onLimitReached callback with inline logging in handler - Update tests to verify logging happens in the rate limit handler - Remove onLimitReached from exports as it's no longer a separate function Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> * Fix fromBlock: 0 in event queries for better performance - Replace fromBlock: 0 with smart default (last 1M blocks) - Add REGISTRY_START_BLOCK env var for configurable starting block - Update make-proof.ts, verification-jobs.routes.ts, and verification-queue.service.ts - Document new env variable in .env.example Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> * Remove hardcoded testnet RPC fallback for production safety - Replace testnet fallbacks with proper error handling when RPC_URL is not configured - Update registry.service.ts, blockchain.service.ts to throw errors if RPC_URL missing - Update CLI scripts (verify.ts, register.ts, make-proof.ts) to fail fast without RPC_URL - Update API routes to return 503 error when RPC_URL is not configured - Update .env.example to emphasize RPC_URL is required Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> * Add documentation for dual Prisma generators and pin Redis version - Add comprehensive comments in schema.prisma explaining dual generator setup - Document why both generators are needed (API vs Next.js web app) - Pin Redis version to 7.2-alpine in all docker-compose files for reproducibility - Update docker-compose.yml, docker-compose.production.yml, and docker-compose.staging.yml Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> * Address code review feedback - add validation for REGISTRY_START_BLOCK - Add proper validation for parseInt to handle NaN cases - Ensure REGISTRY_START_BLOCK is validated before use - Add comment explaining intentional empty catch block - Prevents invalid block numbers from breaking event queries Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> * Refactor block range validation into shared utility function - Create block-range.util.ts with getStartBlock helper - Extract duplicated validation logic from make-proof.ts, verification-jobs.routes.ts, and verification-queue.service.ts - Improves code maintainability and ensures consistent validation - Add comprehensive JSDoc documentation Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> * Add comprehensive test coverage for block-range utility - Create test/utils/block-range.util.test.ts following existing test patterns - Test valid REGISTRY_START_BLOCK values (positive, zero, large numbers) - Test invalid inputs (NaN, negative, empty string, whitespace) - Test default fallback behavior (current block - 1M) - Test edge cases (low block numbers, decimals, provider errors) - 15 test cases covering all code paths and validation logic Co-authored-by: PatrickFanella <61631520+PatrickFanella@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: onnwee <211922112+onnwee@users.noreply.github.com> Co-authored-by: PatrickFanella <61631520+PatrickFanella@users.noreply.github.com>
Prisma Schema - Single Source of Truth
⚠️ IMPORTANT: This is the ONLY Prisma schema file in the repository.
Schema Location
- Single source:
prisma/schema.prisma(this directory) - Do NOT duplicate: Never create
web/prisma/schema.prismaor any other schema copies
How It Works
The single schema.prisma file generates two Prisma Clients:
-
API/Scripts Client (root project)
- Generator:
client - Output:
./node_modules/@prisma/client - Used by: Express API, CLI scripts
- Generator:
-
Web App Client (Next.js)
- Generator:
client-web - Output:
../web/node_modules/.prisma/client(relative to schema location) - Used by: Next.js web application
- Generator:
Note: The output path is relative to the schema file location (prisma/schema.prisma). This is a standard Prisma pattern for monorepos and ensures both clients are generated correctly regardless of which directory you run commands from.
Commands
Generate Both Clients
# From root directory
npm run db:generate
# Or directly
prisma generate
Generate Only Web Client
# From web directory
npm run prisma:generate
# Or directly
prisma generate --schema ../prisma/schema.prisma --generator client-web
Migrations
# From root directory
npm run db:migrate
# Or directly
prisma migrate dev --name <migration_name>
Why Single Schema?
- No Drift: Schema changes are automatically reflected everywhere
- No Duplication: One file to maintain and version
- Safer Migrations: Single migration history prevents conflicts
- Better DX: Update once, generate twice
Safeguards
If you accidentally create a duplicate schema:
- Delete the duplicate immediately
- Run
npm run db:generatefrom root to regenerate clients - Verify both clients work with your imports