Skip to content

fix(db): bound the Lambda connection pool + DB circuit breaker#38

Merged
rkm1 merged 2 commits into
mainfrom
feat/lambda-connection-pool
Jun 8, 2026
Merged

fix(db): bound the Lambda connection pool + DB circuit breaker#38
rkm1 merged 2 commits into
mainfrom
feat/lambda-connection-pool

Conversation

@rkm1

@rkm1 rkm1 commented Jun 7, 2026

Copy link
Copy Markdown
Member

What & why

The Lambda DB path passed PrismaPg a connection string with ?connection_limit=1, which @prisma/adapter-pg ignores — so each warm execution environment's pool used the pg default max: 10. Under a burst of signups (or a pre-token cache-miss storm) the Lambda fleet could exhaust RDS max_connections and make Postgres reject connections from every client — a global outage, not just failed signups.

Changes

  • lambda-prisma: construct an explicit pg.Pool({ max: 1, connectionTimeoutMillis, idleTimeoutMillis }) and pass it to PrismaPg, so per-Lambda connection count is deterministic (= concurrency, not concurrency × 10). Env-configurable: LAMBDA_DATABASE_POOL_MAX (default 1), LAMBDA_DATABASE_CONNECT_TIMEOUT_MS (default 2000).
  • LAMBDA_DATABASE_PROXY_HOST override so handlers route through an RDS Proxy endpoint when one is provisioned (falls back to the direct instance — default deployment unchanged).
  • Per-environment DB circuit breaker (withLambdaDbBreaker, over the existing DatabaseCircuitBreaker) wired into pre-token (loadFromRds) and post-confirmation (provisioning transaction) so a saturated DB fails fast instead of being retried into the incident.
  • pre-token: emit a cache_miss event so a miss-rate metric can be derived.

Tests

  • New test/unit/lambda/lambda-prisma.test.ts7/7 passing (pool max === 1, connect timeout, proxy-host override, client caching, breaker trip + fail-fast).
  • tsc type-clean for the changed files (the lone pre-existing extensions.ts build error is unrelated — present on main without this change).

🤖 Generated with Claude Code

@rkm1 rkm1 enabled auto-merge (squash) June 8, 2026 04:59
rkm1 and others added 2 commits June 8, 2026 07:07
The Lambda DB path handed PrismaPg a connection string with ?connection_limit=1, which @prisma/adapter-pg ignores, so each warm execution environment's pool used the pg default max:10. Under a burst of signups (or a pre-token cache-miss storm) the Lambda fleet could exhaust RDS max_connections and make Postgres reject connections from every client. Fix: construct an explicit pg.Pool({max:1, connectionTimeoutMillis, idleTimeoutMillis}) and pass it to PrismaPg so per-Lambda connection count is deterministic (env knobs LAMBDA_DATABASE_POOL_MAX / LAMBDA_DATABASE_CONNECT_TIMEOUT_MS); add a LAMBDA_DATABASE_PROXY_HOST override to route through an RDS Proxy when provisioned; add a per-environment circuit breaker (withLambdaDbBreaker over DatabaseCircuitBreaker) wired into pre-token (loadFromRds) and post-confirmation (provisioning transaction) so a saturated DB fails fast instead of being retried; and emit a pre-token cache_miss event for a miss-rate metric.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ening

Cuts 0.10.8 carrying the Lambda DB pool cap (max:1), RDS Proxy host override, and the Lambda circuit breaker from this PR. (0.10.7 was the generic entity-feed release.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@rkm1 rkm1 force-pushed the feat/lambda-connection-pool branch from 7354d00 to 3bc9f07 Compare June 8, 2026 05:09
@rkm1 rkm1 merged commit 1cff104 into main Jun 8, 2026
9 checks passed
@rkm1 rkm1 deleted the feat/lambda-connection-pool branch June 8, 2026 05:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant