oRPC のプロシージャが投げた想定外の例外の原因が、応答にもサーバーのログにも残らない

症状

apps/web/server/routes/rpc/[...].ts は @orpc/server/fetch の RPCHandler をそのまま呼んでいて、例外を記録する経路を持たない。プロシージャが ORPCError ではない例外を投げた場合、呼び出し元には INTERNAL_SERVER_ERROR だけが返り、原因はどこにも残らない。

2026-09-18 に feat/merge-auth-collection の d8feaca で測った。DATABASE_URL を設定し、STRIPE_SECRET_KEY を設定しない状態で開発サーバーを起動し、次を実行した。

curl -s -X POST http://localhost:3199/rpc/prices/list \
  -H 'content-type: application/json' -d '{"json":{}}'

応答は次のとおりで、開発サーバーの出力は 1 行も増えなかった（実行の前後で行数を数えて確かめた）。/rpc/products/list でも同じだった。

{"json":{"defined":false,"code":"INTERNAL_SERVER_ERROR","status":500,"message":"Internal server error"}}

これは packages/api/src/stripe/client.ts の StripeClient が SDK を生成する時点で投げる素の Error が、oRPC の既定の 500 に丸められる経路である。

対照として、buildRequestContext の中で投げられる例外は記録される。DATABASE_URL を設定せずに同じ呼び出しを行うと、Nitro が [request error] [unhandled] [POST] /rpc/prices/list に続けてメッセージとスタックを出力した。つまり記録が欠けているのは、RPCHandler の内側で投げられた例外に限る。

誰が何を誤るか

運用中に 500 が出たとき、どのプロシージャのどの処理が原因かを調べる手がかりが残らない。設定の欠落と、実装の不具合と、外部サービスの障害を区別できない。

払い戻しの payouts.processApproved は、一覧の取得に失敗したことを例外ではなく戻り値の listError として返し、契約にはエラーとして載せていない。この設計は、運用中の原因調査をサーバーのログに委ねることを前提にしている。RPCHandler の内側の例外がログに出ないままでは、その前提が成り立たない。

直す場所

apps/web/server/routes/rpc/[...].ts の RPCHandler の呼び出し。@orpc/server 1.14.13 の型定義には interceptors が現れるが、これは同梱の実装を読んだだけの観測なので、実装するときに公式ドキュメント（https://orpc.unnoq.com ）で確かめる必要がある。

決めること

• 何を記録するか（プロシージャの経路、例外の種類とメッセージ、スタック）
• 記録してはいけないもの（入力に含まれるメールアドレス、Stripe の鍵、セッションの値）をどう除くか
• 記録する先（標準出力か、運用先の収集の仕組みか）

直さずに残した理由

何を記録するかを決めずに例外の内容をそのまま出すと、入力に含まれる個人情報や資格情報がログに載る。決める作業を先に要する。

Start at apps/web/server/routes/rpc/[...].ts and reproduce the missing-log case with the documented curl request; then verify @orpc/server 1.14.13 interceptor behavior against the official docs. Define a safe logging policy for the procedure path and exception details without inputs or secrets, and confirm handler-thrown failures are recorded while existing context-error logging remains intact.