[5ym]

概要

#183 で sass と一緒に sirv が消え、server.js が /_app/immutable/* へのリクエストに応答しなくなっていました（ハングする）。そのため Blades を含む app.css などが読み込まれず、本番の表示が崩れていました。

sirv を戻すのではなく、server.js と共有ボリュームの仕組みごとやめて adapter-node 標準に戻します。

変更

• server.js・docker-entrypoint.sh を削除し、CMD [ "build/index.js" ] に戻す
• 共有ボリューム xool-assets（PVC とマウント）を削除。ArgoCD の prune で PVC も消える
• SHUTDOWN_TIMEOUT は adapter-node の index.js が読むので、deployment のコメントだけ直す

トレードオフ

ローリングアップデート中のごく短い間、新旧 Pod の間でアセットが 404 になることがある。これは SvelteKit の再読み込みと +layout.svelte の preloadError 処理に任せる。

🤖 Generated with Claude Code

https://claude.ai/code/session_014FPFCo16TPsUrao9sVBUyi

[claude]

Claude finished @5ym's task in 15s —— View job

---

レビュー結果

問題なしです。

• 不具合: server.js は /_app/immutable/* を sirv で配信し、未ヒット時は元の URL に戻して handler にフォールバックします。fix sass #183 で消えた分岐(リクエストに応答せずハングしていた箇所)が復活しているため、ハングは解消される見込みです。
• 依存関係: Dockerfile の prod-deps は bun i --frozen-lockfile --production なので、sirv を dependencies に置いたのは正しいです。bun.lock の workspace エントリも package.json と一致しています。
• セキュリティ: sirv はパスの正規化とルート外参照の防止を行います。新たな入力経路やシークレットの混入はありません。
• テスト: 配信まわりのテストはありません。ただし、今回の変更は fix sass #183 以前の状態に戻すだけです。

(要確認) 私は実行環境で本番のビルドやコンテナを動かしていません。マージ前に、デプロイ後の /_app/immutable/*.css が 200 で返ることを確認してください。

[claude]

Claude finished @5ym's task in 33s —— View job

---

レビュー結果

最新コミット (b289269) で内容が変わっていたため、現状の差分 (origin/main...HEAD) を見直しました。大きな不具合は見つかりませんでした。PR 説明の更新と、ローリング更新時の挙動の確認をお願いします。

1. PR 説明が現状とずれています

• 説明には「server.js を fix sass #183 より前の内容に戻す」「sirv を dependencies に戻す」「bun.lock に sirv を追加」とあります。
• 実際の差分は、server.js と docker-entrypoint.sh の削除、共有アセット用 PVC の削除、CMD [ "build/index.js" ] への変更です。
• package.json に sirv はなく、bun.lock も差分に入っていません。
• 前回のレビュー (sirv 前提) は今の内容には当てはまりません。説明を実態に合わせて直してください。

2. ハングの原因は解消される見込みです

• 原因は、fix sass #183 で入った独自 server.js が /_app/immutable/* に応答しなかったことです。
• 標準の build/index.js に戻せば、adapter-node のハンドラが自ビルドのアセットを配信します。
• SHUTDOWN_TIMEOUT も adapter-node の index.js が処理するので、deployment.yaml のコメント変更は正しいです。
• terminationGracePeriodSeconds: 45 の前提 (preStop 5 秒 + 30 秒) も変わっていません。

3. 要確認: ローリング更新中の旧チャンク 404

• server.js のコメントによると、共有アセット用 PVC は「新旧 Pod が同居する間に、旧 HTML が参照するチャンクが 404 になる」問題への対策でした。
• 今回その仕組みごと外れるため、maxSurge: 1 の更新中は、旧 Pod の HTML から読み込んだクライアントが新 Pod に当たると、旧ハッシュのチャンクが 404 になり得ます。
• 本番が壊れている状況の暫定対応としては妥当だと思います。意図した割り切りなら、PR 説明に一言あると親切です。
• 恒久策が必要なら、別途検討が必要です。

4. 要確認: 孤立する xool-assets PVC

• マニフェストから PVC が消えます。GitOps (Argo CD など) で prune が有効なら、クラスタ上の xool-assets は削除されます。無効なら残ったままになります。
• 中身は再生成可能なので、どちらでも害は小さいはずです。k8up のバックアップ対象にもなっていたため、意図どおりか確認してください。

セキュリティ・テスト

• 新たな入力経路やシークレットの混入はありません。
• 配信まわりのテストはありません。今回は削除と巻き戻しが中心なので追加は不要と考えます。

私は実行環境にビルドやコンテナがなく (node_modules 未インストール)、adapter-node のハンドラの実物は確認できていません。マージ前に、デプロイ後 /_app/immutable/*.css が 200 で返ることを確認してください。