SwingCompass 本番修正記録

Redis を使う処理が、すべて AuthenticationError で 500 になっていました。パスキーの challenge 保存（backend/app/routers/passkey.py:165）と、Celery への解析投入です。

Fly の [processes] のコマンドはシェルを通らずに実行されるため、${REDIS_PASSWORD} が展開されません。この文字列そのものが Redis のパスワードになっていました。API と worker の REDIS_URL には本物のパスワードが入っているので、認証が合いませんでした。

• 実測: 文字列 ${REDIS_PASSWORD} で redis-cli -a すると PONG、secret の値では WRONGPASS

@@ -10,11 +10,14 @@ # 起動コマンド+# Fly は process コマンドをシェルを通さず実行し ${VAR} を展開しない。+# 直書きすると "${REDIS_PASSWORD}" という文字列がパスワードになる (2026-10-16 本番で発生)。+# 必ず sh -c で包んで環境変数を展開させる。 [processes]-  app = "redis-server --requirepass ${REDIS_PASSWORD} --appendonly yes --dir /data"+  app = "sh -c 'exec redis-server --requirepass \"$REDIS_PASSWORD\" --appendonly yes --dir /data'"

• Redis を再デプロイした後、API から ping → True
• 文字列 ${REDIS_PASSWORD} での認証 → 失敗
• パスキーのログイン開始（options）→ 200

swing.aicompass-golf.com を初めて開いてログインすると、ボタンが「LOGGING IN...」のまま止まりました。ログインの API 自体は成功していて（トークン保存済み・/auth/me 200）、再読み込みするとダッシュボードが開きました。

ログイン画面が表示されたときに /dashboard を router.prefetch していました。その時点では sca_token cookie が無いので、middleware（frontend/src/middleware.ts:12-16）が先読みを /auth/login?redirect=/dashboard にリダイレクトし、Next.js（15.1.9）がその結果をキャッシュします。ログイン後の router.push('/dashboard') はキャッシュを使って通信せず、ログイン画面に留まります。pending は成功時に戻さない作りなので、ボタンの表示がそのまま残りました。

sequenceDiagram
  participant B as ブラウザ（ログイン画面）
  participant RC as Router のキャッシュ
  participant MW as middleware
  participant API as API
  B->>MW: 表示時に prefetch /dashboard（cookie なし）
  MW-->>RC: /auth/login?redirect=/dashboard へリダイレクト
  Note over RC: この結果を /dashboard 用に保持
  B->>API: POST /auth/login
  API-->>B: 200（トークン）→ cookie sca_token を保存
  B->>RC: router.push('/dashboard')
  RC-->>B: キャッシュを返す → URL は /auth/login のまま

• 本番で再現: cookie なしでログイン画面を開くと、/dashboard への通信は先読みの 1 回（104 ms）だけでした。cookie を戻して push しても 5 秒後にログイン画面のままで、router.refresh() の後に push すると /dashboard に移りました
• next dev は prefetch しないので、ローカルでは起きません

@@ -56,12 +56,6 @@     return raw.startsWith("/") && !raw.startsWith("//") ? raw : "/dashboard";   }, [searchParams]); -  // 遷移先を事前コンパイル/プリフェッチしておき、ログイン直後のちらつきを防ぐ-  useEffect(() => {-    router.prefetch(redirectTo);-    router.prefetch("/dashboard");-  }, [router, redirectTo]);-

// src/middleware.ts の PROTECTED_PATHS と同じconst PROTECTED_PATHS = ["/dashboard", "/sessions", "/admin", "/my-coach"]; it.each([  ["redirect 指定なし", ""],  ["redirect=/sessions/123", "redirect=/sessions/123"],])("ログイン前に保護ページを prefetch しない (%s)", (_label, search) => {  mockSearch = search;  // render は act で包まれるので、戻った時点でマウント時の effect は実行済み  render(<LoginPage />);  expect(prefetchedProtectedPaths()).toEqual([]);});

• 回帰テスト: 修正前のコードで 2 件とも失敗（受け取った値 ["/sessions/123", "/dashboard"]）→ 修正後に通過。frontend の jest は 67 件すべて通過
• Codex レビュー: 指摘 0 件
• 本番（Vercel の production、commit b9a2c57）: cookie なしでログイン画面を開いて 3 秒間、/dashboard への通信は 0 件。cookie を戻して push すると、5 秒後に /dashboard
• 利用者として、ログアウト → パスキーでログインしてダッシュボードまで移れた

変わる点: ログイン後の /dashboard の読み込みは、ボタンを押した後に始まります。その間は「LOGGING IN...」の表示が続きます。

10/16、本番で新規登録しても確認メールが届きませんでした。本番 API に EMAIL_PROVIDER が設定されておらず、既定値の console（backend/app/config.py:242）のままでした。console はメールを送らず、本文をログに書くだけなので、確認トークン入りの本文が本番のログに出ていました。

当日の対処は Fly secrets の設定だけです（EMAIL_PROVIDER=resend ほか）。この PR は、同じ設定ミスが再び起きたときに止めるためのものです。

本番 worker は ENVIRONMENT=production ですが、EMAIL_PROVIDER を持っていません（未設定なので console 扱い）。共通の Settings の validator に入れると worker が起動しなくなるので、API の lifespan にだけ置きました。worker はメールを送らず、app.main も import しません（scripts/worker_entry.py → app.celery_app）。

+def assert_email_configured_for_production() -> None:+    """本番で送信できない EMAIL_PROVIDER 設定なら API を起動させない。"""+    if settings.ENVIRONMENT != "production":+        return+    # _send_email と同じ判定にそろえる (ここだけ緩めると起動後に送信で落ちる)+    provider = settings.EMAIL_PROVIDER.lower()+    if provider != "resend":+        raise RuntimeError(+            f"本番では EMAIL_PROVIDER=resend が必要です (現在: '{settings.EMAIL_PROVIDER}')。"+            " console のままだとメールは送られず、本文がログに出ます"+        )+    if not settings.RESEND_API_KEY.strip():+        raise RuntimeError("本番では RESEND_API_KEY の設定が必要です (EMAIL_PROVIDER=resend)")

 async def lifespan(app: FastAPI):-    # 起動時: DBテーブルを自動作成+    # 起動時: 本番でメールが送れない設定なら、DB に触る前に止める+    assert_email_configured_for_production()+    # DBテーブルを自動作成     await init_db()

-google-genai>=1.0.0+google-genai==1.55.0-rtmlib>=0.0.13+rtmlib==0.0.15

保証するのは「resend が選ばれ、キーが入っている」ことまでです。キーの有効性と送信元ドメインの検証状態は見ません。送信に失敗しても send_* がログ（Failed to send email）に書くだけで、呼び出し元には返りません。

backend/tests/test_email_guard.py: ガード単体 7 件と、fastapi_app.router.lifespan_context を通すテスト 2 件。既存の client fixture は ASGITransport なので lifespan を実行しません。lifespan からの呼び出しを消すと、このテストが 1 件失敗することを確かめました。

失敗している 12 件は main と同じテストです。test_passkey 4 件、test_sso 3 件、test_phase2〜4 の DB 保存 4 件、test_storage_service の署名付き URL 1 件。

• 実装前の仕様を Codex がレビュー: P1 2 件・P2 8 件。8 件を取り込み、2 件は見送り（ENVIRONMENT の大文字小文字の揺れ: 既存の JWT ガードも完全一致で判定し、値は infra/fly/api/fly.toml に固定。alembic stamp head がガードより先に走る: 今も起動のたびに走っている既存の動き）
• 実装後のブランチを Codex がレビュー: 指摘 0 件

2026-10-17、版を本番とそろえたイメージ deployment-01M540H8PK2EFWK9K6FHGCK3DD（次の項目）を --strategy bluegreen で入れました。API のマシンは 1 台です。

• /health → 200 {"status":"ok",...}。Fly の health check は passing
• 起動ログ: Application startup complete.。RuntimeError なし
• パスワード再設定メール: 受信を確認。ログに Email sent to … (subject: 【SwingCompassAI】パスワード再設定のご案内)。Failed to send は 0 件
• 戻すときは前のイメージ deployment-01M1PF7ADZ5C5YY8MZ6AQR72V3 を指定する。このイメージにはガードが無いので、戻す前にメールの設定を確かめる（DEPLOY.md §8）

PR #11 を入れるためにイメージを作り直すと、稼働中のイメージ（2026-09-04 ビルド）と比べて Python 3.11.16 → 3.11.17、pip の部品 28 件、OS の部品 31 件の版が変わりました。python:3.11-slim と、requirements.txt の版指定 36 件だけでは固定されません。python:3.11.16-slim も同じ名前のまま作り直されていました（2026-09-19）。

モデル（backend/models/、git 管理外）は、ビルドした Mac に 12 件ありませんでした（motionagformer_b_h36m.onnx ほか。backend/app/config.py:123 の既定値が参照するファイル）。

-FROM python:3.11-slim AS deps+FROM python:3.11.16-slim@sha256:9534e5a8e315485d4061ed659af0fd78a284c015f9b73661b41d6bab25604534 AS deps+ARG DEBIAN_SNAPSHOT=20260904T150500Z-RUN apt-get update && apt-get install -y \+RUN sed -i (apt の取得先を snapshot.debian.org/archive/…/${DEBIAN_SNAPSHOT} に置き換え) \+    && test "$(grep -c '^URIs: http://snapshot.debian.org/archive/' …)" = 2 \+    && ! grep -q '^URIs: http://deb.debian.org/' … \+    && apt-get -o Acquire::Check-Valid-Until=false update && apt-get install -y \-COPY requirements.txt .+COPY requirements.txt constraints.txt ./-    && pip install --no-cache-dir -r requirements.docker.txt+    && pip install --no-cache-dir -r requirements.docker.txt -c constraints.txt

• digest は docker-library/repo-info の 2026-09-02 時点の記録です。amd64（sha256:d1053354…）の 4 層が、稼働中イメージの先頭 4 層と一致しました
• DEBIAN_SNAPSHOT は、稼働中イメージの履歴で apt-get update が走った時刻です。置き換えが当たらず deb.debian.org が残った場合はビルドを止めます
• backend/constraints.txt（新規）: 稼働中イメージの pip freeze 116 件
• backend/.dockerignore: !constraints.txt（既存の *.txt 除外に当たるため）、models/*.pt、.claude/
• モデル 12 件は稼働中イメージから取り出して backend/models/ に置きました（md5 17/17 一致）

投入前に手元（amd64 エミュレーション）で import app.main, cv2, onnxruntime, mediapipe, rtmlib が通ることを確認しました。

• PR #13 を Codex がレビュー: P1 1 件「mediapipe 経由の jax==0.7.1 が numpy>=2.0 を要求し解決できない」。稼働中イメージの jax / jaxlib のメタデータは numpy>=1.26、pip check は No broken requirements found.、ビルドも成功したので対応していません
• PR #14 を Codex がレビュー: 指摘 0 件

• OS の部品は、DEBIAN_SNAPSHOT を書き換えるまで 2026-09-04 の版のままです。Debian の更新は自動では入りません（稼働中のイメージも同じ状態でした）。版の上げ方は DEPLOY.md §8
• ビルドのたびに snapshot.debian.org を使います
• docker compose の backend / worker も、次に作り直すと同じ固定になります。arm64 での作成は確かめていません
• 本番の worker は 2026-09-04 のイメージのままです（infra/fly/worker/fly.toml:9）