読解ライブラリー
空の検索結果と通信失敗を別の画面で伝える
成功した空の量子化検索と、HTTPエラーや未着の応答を分けます。送信した問いを保ち、再試行は意識して選べるようにします。
レスポンスの種類を定める
結果欄が空白なだけでは何が起きたか分かりません。LocalLLaMAノートの例では、処理中、レコードありの成功、空のdata配列の成功、HTTPエラー、利用できる応答を受け取れなかった通信を分けます。それぞれ違う観測です。特に空の成功は関連する議論の不存在を証明せず、応答未着はサーバーが完了したかどうかを示しません。「結果なし」という省略表示に、その解釈を混ぜないでください。
HTTPステータスと検証した応答形式を組み合わせます。200でdata: []なら空の成功取得です。HTTP 400、401、402、429、502はエラーであり、空の成功データの別種ではありません。ネットワーク例外ではHTTPステータス自体がないこともあります。エラーだけからすべてのバックエンド段階を通ったか判断しないでください。条件とアプリのリクエスト識別子を結果ごとに保持し、後の応答を正しい検索へ結び付けます。
空の結果から取れる行動を書く
「このリクエストではレコードが返りませんでした」のように控えめに示します。q=quantization、subreddit=LocalLLaMA、使用中の日付やスコア条件を近くに置き、一つ変えて明示的に再送できるようにします。架空の人気議論で空欄を埋めたり、旧ラベルのまま自動的に検索を広げたりしないでください。フィルターを外したら、その後の結果は新しい条件のものであり、1ページ目の系列から始めます。
欠落の原因を断定せず、関係しそうな条件を説明します。quantization memoryでは解析語が同じtitleかtext内でそろう必要があり、二つのフィールドへの分散では足りません。これは考慮点であって、その応答が空だった原因の証明ではありません。課金上の違いも残します。空でも成功なら1クレジットです。深い空ページでは総数不明の場合もあります。全アーカイブに一致がないという主張や、延々とページを要求する理由にしないでください。
失敗時に取れる行動を書く
対応できる人にエラーを結び付けます。HTTP 400なら未対応パラメーターやYYYY-MM-DDではない日付など、実際の入力を確認します。401はサービスのAPIキー、402はサービスアカウントの残高の問題で、読者自身のアプリへのログイン切れを示すものではありません。運用者によるバックエンドの認証情報や残高の確認が必要な場合があります。公開検索画面にサービスキーを貼るよう読者へ求めないでください。
429ではRetry-Afterを尊重して連続送信を減らします。502ではクエリを残し、適切なら意図的な再試行を用意します。予約クレジットの返金が照合待ちの場合もあります。応答未着では「結果が分からず、成功課金の有無も不明」と別に伝えます。予約前に却下した不正なリクエストは非課金ですが、接続失敗だけでその却下が起きたとは言えません。無料の/v1/statusは静的な説明とHTTP応答を示すだけで、失われたリクエストの結末や検索系の健全性を確かめません。
移動しても状態が保たれるか試す
連続性には入力の保存も含まれます。妥当な空応答、HTTPエラー、応答前のネットワーク例外を再現するローカルなフィクスチャーを計画します。架空の材料と明示し、画面の検証であってアーカイブ可用性の証明ではないと区別します。表示が異なり、送信したクエリへ戻れるかを確認します。処理中にフォームを変えるケースも追加し、古い結果が新しい語への回答として出ないようにします。
次ページの取得が失敗しても、取得済みレコードは残し、完了済み状態と失敗した継続を分けます。次の要求を黙って送らず、同じページを再試行するかフォームへ戻るか選ばせます。遅れた応答を画面で無視しても、サーバー処理の取り消しは保証されません。実際に試した遷移と計画段階の遷移を別に記録します。目指すのは、根拠のない安心表示ではなく、既知の状態と役立つ選択肢を示す画面です。
