Elanorya

実行と失敗

失敗した実行が、ひとりでにもう一度試されることはない理由

生成は、プロバイダー実行がちょうど一回だけ行われるようにキューへ入ります。その実行が失敗すれば、ジョブはそこで終わりです。列に戻ることはなく、失敗すればクレジットは返金されます。コードの中にある再試行という言い回しは、キューがどの速さで進むかを述べたものであって、画像への二回目の挑戦ではありません。

一回の実行、そこでジョブは終わり

生成を送信すると、アプリはキューにジョブを一つ置き、attempts: 1を設定します。この数字がすべてです。プロバイダー実行はちょうど一回行われ、そこから返ってきたものが、そのジョブにとっての最終結果になります。

実行が失敗しても、ジョブが列に戻ることはありません。失敗として終わり、クレジットは返金されます。頼れる残りの試行がないからこそ、待っているあいだ何も変わりません。

次のプロバイダー実行は、新しい生成を始めたときにだけ存在します。もう一枚の画像を生むのは、その操作だけです。

失敗した実行に対してコードがすること

このうち四つはジョブそのものを説明します。最後の二つは分類と受け渡しの説明で、しばしばジョブの話と取り違えられます。

ジョブはattempts: 1でキューへ入ります。
ジョブ一つにつきプロバイダー実行はちょうど一回だけ許されるので、失敗した実行の後ろには何もありません。
失敗すればクレジットは返金されます。
ジョブは失敗として終わり、クレジットが返金されます。このページはそれ以上のことを述べません。金額もなく、返金ポリシーもありません。
再試行の分類はありますが、それはジョブについてのものではありません。
レート制限（429）、プロバイダー側のサーバーエラー（5xx）、ネットワークエラーは、プロバイダー層で再試行可能というラベルが付けられます。このラベルは速さの調整に使われるもので、生成をやり直すためのものではありません。
retry-afterの値はキューを遅くします。
値はペナルティとしてリミッターへ渡され、処理はゆっくり流れるようになります。それが効き始めるころには、実行はすでに終わっています。
まったく再試行不可と分類される結果もあります。
安全性によるブロック、不完全な応答、画像ではなくテキストとして返ってきた応答は、それぞれ再試行不可に分類されます。
背景削除では、透過のない結果は失敗として数えられます。
不透明なまま素通りした結果は、届けられたものとしてではなく失敗として記録されるため、仕上がった結果としては扱われません。

それぞれの失敗がどう分類され、それが何を変えるか

分類はプロバイダー層にあります。三列目をよく読んでください。どの行でも、ジョブは終わっています。

返ってきたものコードによる分類分類が変えるもの
レート制限（429）再試行可能retry-afterの値がリミッターにペナルティを与え、キューはゆっくり進みます。ジョブが再実行されることはありません。
プロバイダー側のサーバーエラー（5xx）再試行可能速さへの効果は同じです。ジョブが再実行されることはありません。
ネットワークエラー再試行可能速さへの効果は同じです。ジョブが再実行されることはありません。
安全性によるブロック再試行不可何も繰り返されず、何も遅くなりません。ジョブは終わります。
不完全な応答再試行不可何も繰り返されず、何も遅くなりません。ジョブは終わります。
画像ではなくテキストが返ってきた場合再試行不可何も繰り返されず、何も遅くなりません。ジョブは終わります。

失敗した実行が終わるまで、順を追って

送信から停止するところまで、サーバー上でのジョブの一生です。

  1. 実行を送信する

    アプリはジョブを一つ作り、attempts: 1でキューに置きます。

  2. プロバイダーが一度だけ呼ばれる

    この一回の呼び出しが実行のすべてです。そこで返ってきたものが、ジョブの結果を決めます。

  3. 失敗が分類される

    エラーには再試行可能か再試行不可のラベルが付きます。再試行可能に入るのは、レート制限、プロバイダー側のサーバーエラー、ネットワークエラーです。

  4. retry-afterの値が返ってきていれば、キューが遅くなる

    値はペナルティとしてリミッターへ渡されます。変わるのはキューの速さであって、ジョブの行方ではありません。

  5. ジョブが失敗として終わる

    頼れる残りの試行はなく、失敗すればクレジットは返金されます。

  6. 自分が動くまで、その先は何も起きない

    次のプロバイダー実行は、新しい生成を始めたからこそ存在します。

カタログ作業の一日で、これがどこに効いてくるか

このページの向きがいちばん効いてくるのは、多くの作品をまとめて進めているときです。

  • 失敗した実行がひとりでに片づくと考え、出品が空のままになる。

    失敗を見た時点でそれを終わったものとして扱い、まだ画像が必要なら自分でもう一度実行を始めてください。

  • レート制限の続く時間帯が、二回目を待っている自分のジョブの集まりのように見える。

    そうではありません。retry-afterの値はキューを遅くします。失敗した自分のジョブが、その中で実行を待っているわけではありません。

  • 良くない結果を報告して、それが再試行や精算として働くことを期待する。

    シートにはそのまま書かれています。報告はコンテンツ審査を始めるものであり、金銭やクレジットを自動的に返金するものではありません。届かなかった場合は、クレジットの仕組みが別に扱います。

  • 調子の悪い時間帯に、同じリクエストを繰り返し送り直す。

    同じ冪等キー（idempotency key）を持つ再送信は、二つ目を始めるのではなく、すでにある生成を返します。送信を繰り返しても作業が増えることはありません。

実行が失敗して戻ってきたときにすること

順番どおりに。どれにも、待つことは含まれません。

  • 結果をそのジョブの最終結果として読む。プロバイダー実行は一回行われ、それで終わっている。
  • まだ画像が必要かどうかを決める。必要なら、新しい実行を自分で始める。
  • もう一度送信する前に、確認のステップで操作にかかる費用と、そのあとに残ると見込まれる残高を確かめる。
  • 画像は届いたが内容が誤っている場合は、報告シートを使う。開くのはコンテンツ審査であって、二回目の実行ではない。
  • そもそも実行が始まらなかった場合は、原因も専用のページも別にある状態として扱う。

このページが扱わないこと

以下はいずれも、別のページが扱っているか、アプリが記録していないものです。

  • 実行中にクレジットがいつ使われるのか、いつ保留されるのかは述べません。その瞬間は、専用のページが扱います。
  • 金額は示さず、返金ポリシーやストアでの金銭の返金手続きについても説明しません。登録されている事実は、失敗すれば返金されるという一点だけです。
  • 安全性によるブロックが何に反応するのかは説明しません。
  • プロバイダー層の内部エラーの文言を、そのまま載せることはしません。
  • キューがどう組まれているのか、ほかに誰が入っているのかは説明しません。ここで述べる効果は、キューが遅くなるという一点だけです。
  • 待機画面が何を示すか、生成が始まらないことがあるのはなぜか、終わったジョブのうちどれが記録からもう一度実行できるかは扱いません。それぞれに専用のページがあります。

よくある質問

生成が失敗しました。待っていれば、アプリがひとりでにもう一度試してくれますか？

いいえ。ジョブはattempts: 1でキューへ入るため、プロバイダー実行はちょうど一回起こります。その実行が失敗した時点でジョブは終わり、クレジットは返金されます。二回目の実行は、自分で始めたときにだけ存在します。

失敗にレート制限とありました。ジョブが二回目を待っているということではないのですか？

違います。レート制限、プロバイダー側のサーバーエラー、ネットワークエラーは再試行可能に分類され、retry-afterの値はリミッターへ渡されてキューがゆっくり進むようになります。この分類が調整するのはキューの速さであり、ジョブを再実行するものではありません。

失敗した実行のクレジットはどうなりますか？

失敗すれば返金されます。このページは金額を示さず、返金ポリシーも説明しません。実行中にクレジットがいつ使われるのかは、専用のページが扱います。

良くない結果を報告すると、新しい実行が始まりますか？

いいえ。報告シートにそのまま書かれているとおり、報告はコンテンツ審査を始めるものであり、金銭やクレジットを自動的に返金するものではありません。届かなかった場合は、クレジットの仕組みが別に扱います。