ERROR：【JOB】has been attempted too many times or run too long.

エラー：【JOB】has been attempted too many times or run too long.

他社売価を調べるJobの結果を見ていたところ、奇妙な現象を発見しました。

何故か同じレコードを３つ持っている奴がいる…。

全ての商品でレコードを３つづつ持っているならまだしも、３つ持つものと１つ持つものが存在していました。
ログを確認したところ、タイムアウトエラーが記載されていました。

しかし、このエラーの前に次のようなLOGが。

ERROR：4954057104197=>Invalid JAN identifier 4954057104197 for marketplace A1VC38T7YXB528

これは日本Amazonに出品が無い事を意味しています。まぁ【ERROR】でアナウンスされていてはダメで回避処理しないといけないのですが、そこは今回おいておいて、レコード重複の原因は３回繰り返されている【JOBスタート】でした。

JOBが３回走った理由

価格調査JOBでは以下の仕掛けをしていました。

Job実行に失敗しても３回までは試行してねという奴です。
その為、３回繰り返し４回目にタイムアウトエラーを吐いていました。

となると、実質はタイムアウトエラーではなく別のエラーが問題ということになります。
最初、重い処理だからタイムアウトが発生したのだと思ってましたが、全然理由は違ったわけです。

本当の理由はSQLに存在しないレコードの存在しない値を代入していたからだった

こんな感じのパーツがあったとします。

今回の原因は１個目のSQLで $value に値が無い事が原因でした。$value=NULLなので$value->idが存在しません。それなのに抽出条件に入れていたためエラーで繰返し処理が発生していました。

う～ん、こうなると「全商品でデータが取れている」と思ってたけど取れてないって事だろうなぁ。

NULLの時の処理を書き加えて解決

１個目と２個目のSQLコードを変更しました。

これで無事にエラー回避。

まとめ

テストでは上手くいっても実際のレコードで実行すると上手くいかない事は多々あります。
すぐにバックグラウンド処理に回さないで、一回syncで実行しておけばよかったと少し後悔しつつ、それやるとほかの作業止まるしなぁ～と悩んでる自分がいます。

最も効率的な正解はBackgroundで処理させつつひたすらログを採る事かなぁ。