まとめ申込みで対象枠が追加されなかったとき、bundleUnavailableを足すまで『割引なし』としか伝わらなかった

結論

複数の広告枠をまとめて申し込む機能で、対象枠が保有済み・満枠・DBエラーなどの理由で提示から消えたとき、完了メッセージは「割引が適用されません」としか伝えておらず、対象枠そのものが申し込みに追加されなかった事実を伝えていなかった。 チェックボックスを入れた人は「一緒に申し込めた」と思っている前提で、割引額の話だけでは足りない。

想定されていた事故

このフォームには、1枠を申し込むときに「対象のセット枠も一緒に」というチェックボックスがある。チェックすると、サーバー側でgetQualifierBundleOfferが対象枠を再計算し、保有済みでない枠をまとめて予約する。

const offer = await getQualifierBundleOffer(admin, loopId, result.companyId);
for (const m of offer?.members ?? []) {
  const r = await book(m.loopId);
  if (r.ok) bundleAdded.push(m.label);
  else bundleFailed.push(m.label);
}

offerがnullのとき、つまり対象枠がそもそも提示されなかったときは、このforは一度も回らない。bundleAddedもbundleFailedも空のままで、完了メッセージの組み立てはこの2つの配列と「割引が付いたか」しか見ていなかった。

const bundleNote = !bundleRequested
  ? ""
  : [
      bundleAdded.length > 0 ? `あわせて「${bundleAdded.join("」「")}」もお申し込みを受け付けました。` : "",
      bundleFailed.length > 0 ? `「${bundleFailed.join("」「")}」は満枠等のためお受けできませんでした。` : "",
      bundleDiscountApplied
        ? "セット割引は最後のお申し込み分の金額に反映されています。"
        : "セット割引の適用条件を満たさなかったため、今回は割引が適用されていません。金額について担当者よりご連絡します。",
    ].filter(Boolean).join("");

結果、offerがnullのときは4つの文言すべてが空になり、最後の「割引が適用されていません」だけが画面に残る。チェックした人からすると、「対象枠も申し込んだが割引だけ付かなかった」ように読めてしまうが、実際には対象枠は一枠も申し込まれていない。

原因

getQualifierBundleOfferのnullは、複数の異なる状態を一つにまとめた戻り値だった。対象枠が既に保有済み、満枠、セットが完成する見込みが無い、そして対象枠一覧の取得そのものがDBエラーで失敗した場合——これらすべてが同じnullとして返ってきていた。

const { data: loops } = await admin
  .from("placement_loops")
  .select(/* ... */)
  .in("id", toOffer);

ここではerrorを受け取らず、クエリが失敗してもloopsはundefinedのまま後続の処理に進み、結果的にnullを返す。呼び出し元のactions.tsは、このnullを「提案すべき対象枠が無かった」という一つの意味としてしか扱えず、「対象枠が無かったから何も起きていない」のか「エラーで提案できなかっただけで本来は対象枠があった」のかを区別する手段がなかった。

メッセージ生成側も、offerがnullだったという事実そのものを見ておらず、bundleAdded/bundleFailedが両方空だったという間接的な状態からしか判断できない構造だった。

直し方

修正は2箇所に分かれる。

1つ目はactions.ts側。offerの有無をbundleUnavailableという変数で直接記録し、提示が消えていた場合はメッセージの先頭にその旨を明示する。

const offer = await getQualifierBundleOffer(admin, loopId, result.companyId);
bundleUnavailable = !offer || offer.members.length === 0;
for (const m of offer?.members ?? []) {
  const r = await book(m.loopId);
  if (r.ok) bundleAdded.push(m.label);
  else bundleFailed.push(m.label);
}

const bundleNote = !bundleRequested
  ? ""
  : [
      bundleUnavailable
        ? "なお、まとめてお申し込みの対象枠は、既にご契約済みか現在お受けできない状態のため、今回は追加されていません。"
        : "",
      // ...bundleAdded / bundleFailed / bundleDiscountApplied は変更なし
    ].filter(Boolean).join("");

2つ目はpromo-bundle.ts側。対象枠取得のクエリでエラーを受け取り、黙って握りつぶさずログに残すようにした。

const { data: loops, error: loopsErr } = await admin
  .from("placement_loops")
  .select(/* ... */)
  .in("id", toOffer);
if (loopsErr) {
  console.error("[getQualifierBundleOffer] 対象枠の取得に失敗", loopsErr.message);
  return null;
}

戻り値としては引き続きnullのままだが、DBエラーが起きたこと自体はログから追えるようになった。あわせて、メンバーが2件未満なら割引が成立しないという判定（従来は関数の終盤、DBクエリの後にあった）をDBクエリより前に移し、不要な問い合わせをしないようにした。

再発防止

この状態は「レビュー指摘（N1）」で見つかり、同日中に修正されている。見つかった理由は、offerがnullになる複数の原因（保有済み・満枠・セット未完成・DBエラー）を洗い出し、「nullを受け取った呼び出し元は、その中のどれが起きたのかを一切区別できていない」という点に気づけたことだった。

複数の失敗理由を一つのnull（やfalse、空配列）にまとめる関数は、呼び出し元から見ると「何も起きなかった」のか「起きたが伝える手段が無かった」のかの区別が失われやすい。ユーザー向けのメッセージを組み立てる処理では、個々のフラグの有無ではなく、「サーバー側で実際に何が起きたか」を直接記録した値を見て文面を決める必要がある。