この記事を読んだ方がいい人
同じバグに遭遇した人
この記事を読まない方がいい人
このバグには遭遇してない人
javascriptとは幼馴染な人
経済的に恵まれた大規模プロジェクトの感覚でべき論をふりかざしたい人
やりたかったこと
普通に画面表示
エラー発生ポイント
こんなエラー状況に陥る
Application error: a client-side exception has occurred (see the browser console for more information).
クライアントサイドエラーが起きてるよ。詳しくはconsole見てね。とのこと。
コンソールには
Maximum call stack size exceeded...から始める長めのエラーメッセージが。
エラーが発生した時点ではそこまでハマった実感はありませんでした。
ローカルとStagingでは発生してないのにこんなことあるんだなー。程度。
はまりポイント1個目 TypeScriptへの不慣れさ
ブラウザから見ることのできるコードはコンパイル済みのコードなので一切の有益な情報なんてないと思っていましたが、ここで周辺情報を一つ見落とすことになりました。
コンパイル後のjavascriptのコードでも、自作の処理が問題なのかライブラリ等自分で書いていない処理が問題なのかの判断くらいはつけられるらしいのですが気付けず。
問題になっていたコードはfunction名がアルファベット1文字とかだったので自分で作った処理が直接の原因ではなさそうというところまではこの時点で気づけたはず。
はまりポイント2 自作処理が原因だと思い込む
結果的にこの感覚がフロントエンド初心者ムーブだったなと振り返ります。
経験があればこういう詰まり方はしないかもなと思わされた一番大きいポイント。
結構な差分を含むリリースだったのでひたすらソースコードのロールバックを繰り返していろいろ試しました。
ソースコードを一定まで戻すと元通り動くので絶対に自分のソースが悪いと試行錯誤しますが原因は特定できず。
はまりポイント3 NODE_ENVの影響
今回のリリースではソースの差分も去ることながらStaging環境の配備を同時に行なっていました。
そのためStagingでの実行をするための差分も含まれており、その中でNODE_ENVの値を何度か環境別に書き換えていました。
そのため今回のエラーの発現の一因であるNODE_ENVの違いを紛れ込ませることになってしまったのです。
NODE_ENVがproductionに設定されていると package.json の devDependencies がインストールされません。
状況証拠的にはこれにも関係があったっぽいです。
はまりポイント4 インフラわかってない問題
これはあんまり関係ないのですが修正中に大変だったこととして一応リストアップ。
AWS ECSのタスク定義を更新するときに2つのトラブルが発生しました。
1つ目はロールバックの仕方を知らなかったこと。
ロールバック時にタスク定義のイメージURLを戻したいバージョンに指定し直してあげる必要があることも頭に入っておらずタスク定義だけを戻して、あれ？もどってない。みたいなことをやっていました。
2つ目は、イメージのタグはlatestをつけていたのですが、試行錯誤中に一度Staging向けのイメージを本番のECRリポジトリにPUSHしてしまったことでタスク定義のイメージ向き先がStagingになってしまいました。
その後ロールバック、リリースを繰り返してもイメージがStagingを向きっぱなしでロールバックがうまくいかないという問題に直面していました。
解決
ここからはひとつひとつ解決していきます。
はまぽ1
TypeScriptへの不慣れさは解決というより後から知ったので次はコンソールエラーも多少は参考にすべきだなと。
同時にローカル環境ではsource mapを有効にしてTypeScriptでのデバッグ作業を効率化、本番では絶対オフ。
ということを学びました。
はまぽ2
ライブラリのせいでの障害ということは自分の開発経験上そこまで頻度は高くありませんでした。
javascript界隈では3rdパーティのライブラリに頼る比率がだいぶ高くなりがちみたいですね。
そのためあまりライブラリに頼り過ぎないというのも一つの方針らしいです。
ライブラリがやってくれる処理を自作で作るなんてナンセンスな！と思ってたのですがそれはあくまでもフルスタックなフレームワークに守られたぬくぬくメジャーサーバー言語での開発の話なのかもしれません。
うまく行った修正は下記です
画像周りのライブラリであるsharpとnext.jsのバージョンの組み合わせによって発生するエラーでした。
日本語の情報はほぼなく、上記のGithub issueに助けてもらいました。
バッチバージョンレベルで止めてしまっているので先送りにした状態ですのでバージョンが進んだら解消されているかの検証は必要そうです。
はまぽ3
NODE_ENVがどこに影響を及ぼしているかまるでイメージができていませんでした。
ローカル → development
Staging → staging
本番 → production
とかで分けようと思ってたのですがそもそもNODE_ENVはdevelopment か productionしか想定していないんですね。
玄人から見たらまるでトンチンカンなことをしてるんでしょうが戒めも込めて無知を晒していきます。笑
公式を見るとキャッシュを積極的に使うって書いてあるので、今回のエラーはその辺も影響したのかもしれません。
NODE_ENV=development
NODE_ENV=production
NODE_ENV=production
この最小構成で行くなら環境変数はこれがよさそうです。
はまぽ4
ここに関しては学びはたくさんありました。
今回から少しずつ広告などの経費をかけながら運営を始めているので スピード >>>>> クオリティ で行なっていたもろもろん開発フローを少し見直しの必要が出てきそうです。
まず、本番環境を正常稼働させ続けるため、スムーズなロールバック手順を必ず用意してからリリースへ臨むことにしました。
インフラの知識も増強しつつできればサービス開発に集中できる布陣を作っていけたらなーと思います。
最低限サーバーレスの構成なら一通り自分でできるくらいにはなっていた方がいいのかもしれませんが。
まとめ
フロントエンド入門してから最もヘビーなはまり方をしましたが、こんな感じの経験と比例してパワーアップしていけると信じて立ち向かおうと思う所存です。