fix(prisma): add retry for Aurora Serverless v2 connection errors

[konokenj]

Issue

close #104
close #105

Problem

The starter kit has three issues with Prisma + Aurora Serverless v2 (auto-pause enabled with minCapacity: 0):

1. Credential leak: console.log(process.env.DATABASE_URL) in prisma.ts outputs the full connection string including password to CloudWatch Logs.

2. No runtime retry: Aurora drops idle connections after idle_session_timeout (60s) and takes ~15s to resume from auto-pause (docs). Without retry, queries fail with transient errors (P1017, ECONNRESET) and do not recover.

3. No migration retry: migration-runner.ts runs prisma db push without retry. During cdk deploy, Aurora may still be resuming, causing P1001 ("Can't reach database server") and failing the entire deployment.

Solution

• Remove console.log(DATABASE_URL) to fix the credential leak.
• Add a Prisma client extension (Prisma.defineExtension with $allModels.$allOperations) that retries transient connection errors with exponential backoff. Retryable errors: P2024, P1001, P1017, idle-session timeout, ECONNRESET. Non-retryable errors (auth failures, schema errors) are thrown immediately.
• Add retry to migration-runner.ts for prisma db push with exponential backoff (base 3s, max 5 attempts, ~100s worst case within Lambda 5min timeout). Only P1001 / connection refused are retried.
• Optimize connection parameters: connection_limit=1 (Lambda handles one request per instance), connect_timeout=30 (accommodates auto-pause resume time).

Changes

• webapp/src/lib/prisma.ts — Remove console.log, remove verbose log option, add retry extension via $extends
• webapp/src/jobs/migration-runner.ts — Extract runPrismaDbPush with retry loop, structured logging
• cdk/lib/constructs/database.ts — Change connection options to ?connection_limit=1&connect_timeout=30

Verification

• console.log(process.env.DATABASE_URL) is removed
• After Aurora auto-pause resume, the first request recovers via retry
• Non-retryable errors (e.g. auth failure) are thrown immediately without retry
• cdk deploy succeeds even when Aurora is resuming from 0 ACU
• tsc --noEmit passes
• prettier --check passes

[badmintoncryer]

一点だけコメントです！

[badmintoncryer]

AWS仕様について教えて下さい。

ECONNRESET問題は以下のシチェーションで起きていると想像しています。

1. Lambdaがリクエストを処理し、PrismaがDB接続を確立
2. リクエスト完了後、Lambdaインスタンスはwarm状態で待機(接続はプール内に残る)
3. 60秒アイドルが続くとPostgreSQL側が接続を強制切断
4. 次のリクエスト時、Prismaはプール内の切断済み接続を使おうとする
5. ECONNRESET

ここでidle_session_timeout=0にすることで、lambdaのインスタンスが起動中は同一connection poolを使い回すことができ、各種リトライ処理が不要になる可能性があると思っています。
このときのデメリットはlambdaインスタンスが動き続ける間connectionが張られるため、Auroraが0ACUに落ちないことです。

本題ですが、lambdaの立ち上がったインスタンスってどの程度の期間動き続けるものでしょうか..??
この時間が~10分程度である場合、課金上の問題はほぼ無くなるので、この方針の現実味が出てくるかもと思っています。

[konokenj]

@badmintoncryer ご指摘ありがとうございます！
ECONNRESET 対策なのはおっしゃる通りで、idle_session_timeout=0 にすると根本的に解消できますが、Lambda 実行環境は invocation 間で DB 接続を保持・再利用します。
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html

idle_session_timeout=0 の場合、この接続は Aurora 側から見て user-initiated connection として残り続けるため、auto-pause が発動しないはずです。

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html

Lambda 実行環境の生存期間は公式には非決定的で、数時間残る可能性もあるため、その間Aurora が 0 ACU に落ちなくなります。このスターターキットは minCapacity=0 でのコスト最小化を重視しているので、idle_session_timeout=60s + リトライの現行方針を維持しようと思います。