fix(api): fail closed on missing upstash env in production

[subheeksh5599]

Summary

api/_lib/middleware.ts falls back to a per-process in-memory Map limiter whenever the Upstash env vars are missing, with no signal. Across concurrent Vercel workers that fallback is effectively no limit at all, so a production deploy missing UPSTASH_REDIS_REST_URL/UPSTASH_REDIS_REST_TOKEN silently serves traffic without distributed rate limiting.

This makes the module fail closed: at load time, if VERCEL_ENV === "production" and the Upstash vars are absent, it throws instead of constructing ratelimit as null. Local dev (VERCEL_ENV unset) and preview deploys (VERCEL_ENV="preview") keep the in-memory fallback unchanged.

Test plan

• pnpm --filter @meridian/api test — 26 passed (4 new tests cover the production throw, production-with-vars load, and fallback kept for dev + preview)
• pnpm typecheck:api passes
• pnpm exec eslint on changed files — clean
• pnpm exec prettier --check — clean

Closes #483

[vercel]

@subheeksh5599 is attempting to deploy a commit to the Collins' projects Team on Vercel.

A member of the Team first needs to authorize it.

Redoing this as inline file comments instead of a single review body.

[collinsezedike]

This new describe block runs inside a test file that imports middleware.js statically at the top of the file (line 7). The fix under review moves the production/missing-env check to module load time, so if this test file ever runs in a shell with VERCEL_ENV=production set but the Upstash credentials absent (vercel env pull, vercel build locally, or a future CI job mirroring the Vercel build environment), that top-level import throws and crashes the entire file, taking down all the pre-existing applyCors/rate-limit tests along with these new production-guard ones, not just failing one assertion.

Guard against the ambient environment instead of relying on it never having VERCEL_ENV=production set during a test run. Either unset VERCEL_ENV explicitly in a top-level beforeAll, or move the production-throw test into its own file that imports middleware.js dynamically inside the test body.

[collinsezedike]

These lines assign each saved env var back and then immediately delete it, before the Object.entries(savedEnv).forEach on lines 72-75 does the real restoration. Nothing else executes in between, so the delete calls unconditionally wipe out whatever the assignments just set, and the forEach overwrites the result again right after. They have no effect on the final state and only obscure that the forEach is the actual restoration logic. Delete them.

[subheeksh5599]

Addressed both review points in 74bccfb:

1. Ambient VERCEL_ENV=production crash — reproduced it first: it was worse than reported, handlers.test.ts crashed too (it imports v1/tx/deposit.ts → middleware). Fixed with a belt-and-braces pair:
   • New api/vitest.setup.ts (wired via api/vitest.config.ts) deletes VERCEL_ENV/Upstash vars in setupFiles, which run before test files are imported — the only place that can stop a static-import throw. This protects every api test file, not just this one.
   • The 4 production-guard tests moved to api/__tests__/middleware.rate-limit-guard.test.ts, which imports middleware.js only dynamically inside the test bodies.
2. Dead env-restore lines — removed the assign-then-immediately-delete lines; afterEach now only does the Object.entries(savedEnv) restoration.

Verified: pnpm --filter @meridian/api test passes normally (26 tests) AND with VERCEL_ENV=production exported (previously 2 files crashed); pnpm typecheck:api, eslint, prettier all clean.

[collinsezedike]

Thank you for the fix, and for addressing both review comments cleanly, moving the production-guard tests into their own file with dynamic imports is a better solution than either fix I suggested. Approved.

Feel free to pick up another open issue whenever you're ready.