fix: sign-in 500 — auth rate limit passed raw Date params to postgres.js

[Skeyelab]

Problem

Every sign-in and sign-up attempt on production returned HTTP 500 ("Request failed" in the UI). From the Coolify app logs:

TypeError: The "string" argument must be of type string or an instance of
Buffer or ArrayBuffer. Received an instance of Date
  at Function.str (.next/server/chunks/app_lib_db_ts_0.d9324._.js:1:8507)

Failed query: insert into "auth_rate_limits" ... on conflict ("key") do update
set ... "window_start" = case when "auth_rate_limits"."window_start" <= $8 then $9 ...

This was not a credentials problem — the request died in the rate limiter before credentials were ever checked, so no one could log in at all.

Root cause

postgres.js cannot serialize a raw Date that is interpolated into a drizzle sql fragment; only drizzle's own column-typed bindings get mapped to a driver-serializable value. The atomic upsert introduced in fix: make auth rate limit increments atomic interpolated windowStart and expiredBefore Date objects directly into the case when ... fragments.

Fix

Pre-stringify both timestamps to ISO and cast them back to timestamptz inside the statement. The upsert remains a single atomic statement that increments count in the database, so the original security-review fix still holds.

Tests

Added tests/auth/rate-limit-params.test.ts, which drives the real rate-limit module through drizzle's pg-proxy driver and asserts:

• no raw Date ever reaches the driver (this test fails on the old code with the exact 3 offending params)
• the statement is still a single on conflict upsert with an in-database "count" + 1

Verification

• yarn lint ✅
• yarn test:run ✅ 68 files / 291 tests
• Verified against a real Postgres 16 instance (not just mocks): migrations apply, insert path, the conflict/upsert path that was 500ing, atomic increment to count=5, throttling engaging with retryAfterSeconds=900, and a full sign-up → wrong-password 401 → correct-password 200 flow.

[strix-security]

Strix Security Review

No security issues found.

Review summary

Reviewed both changed files: the rate-limiter fix in app/lib/auth/rate-limit.ts and the new regression test. The change pre-stringifies two server-generated Date values to ISO strings and casts them with ::timestamptz inside the atomic upsert's case when fragments. The interpolated values are produced by Date.toISOString(), not attacker-controlled input, and are emitted as bound parameters, so there is no SQL injection surface. The window_start column is timestamp with time zone, so the cast is type-correct. The atomic single-statement upsert and in-database count + 1 increment are preserved, and key/kind remain parameterized. No security control was weakened and no new tainted-input path was introduced; no vulnerabilities were identified.

_{Updated for 174a61a.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}