どうもこんにちは。
今回は、AWS Elastic Beanstalk環境にデプロイした時に発生した499エラーの原因を解決したので、備忘録として残します。
何が起きていた？
当初は、以下の流れでデプロイをしていきたいと思っていました。
- ソースコードを
git commit -
eb deploy実行 - URLにアクセスして動作確認
しかし、3番目で499エラーが発生してしまいました。（画面上では、502や504が表示されます。)
原因はなんだったん？
499エラーの原因は、libディレクトリにありました。
開発者や組織によると思いますが、自分の触っているRailsアプリでは、libディレクトリをeager_load_pathに追加していました。
config/application.rb
class Application < Rails::Application
config.eager_load_paths << "#{config.root}/lib"
end
なんでeager_load_pathにしたらいけなかったの？
eager_load_pathに特定のディレクトリを指定すると、Railsサーバーが立ち上がった時に、自動で実行されてしまいます。自動で実行したい場合には、eager_load_pathに追加してもいいのですが、何も知らずにeager_load_pathに追加してしまうのは避けたいです。
ただ、気をつけていただきたいのが、libディレクトリをeager_load_pathに追加したらダメ というわけではないです。
一番言いたいことは、eager_load_pathにlibディレクトリを追加したなら、バリデーションに引っ掛かるようなスクリプトはlibディレクトリには保存しない！ ということです。
どんなコード書いてたの？
こんなコード書いていました。
class Tasks::DeleteFormatColumn
content_items = ContentItem.where(format: %w[PNG JPEG BMP])
content_items.each do |content_item|
# 処理
content_item.save!
end
end
content_item.save!が実行される前に、バリデーションに引っ掛かるようなデータを作ってしまうような処理を行なっていました。
はぁ...
ということで、eager_load_pathに追加されていないディレクトリにファイルを避難して解決です。