下書きの列が2つ目のマーカーで先頭から進まなくなっていた
今回やったこと
記事の下書き本文に挿絵用マーカーが2つ入ったとき、画像処理と公開キューが別々の前提で動き、先頭の記事が後続を止める問題を修正した。画像処理は最初のマーカーだけを画像に置き換え、処理済みとして記録していた。公開側は残った2つ目のマーカーを未解決と判断して公開を保留した。その結果、画像処理は完了と認識して再実行せず、公開側は記事を通さない状態が続いた。
対処では、マーカー数と差し込み規則の判定を一つのスクリプトに集約した。マーカーがちょうど1つでなければ画像生成前に止め、起稿直後と変更を取り込む前の両方で同じ条件を確認する。
それぞれの「完了」が食い違った
この障害は、単一の処理が失敗したのではなく、工程間の状態の解釈が違っていた。画像処理側は「1枚作って差し込んだ」ことを完了条件にしていた。公開側は「本文に未処理のマーカーが残っていない」ことを条件にしていた。どちらも局所的には合理的でも、前提が共有されていないために一方の完了が全体の完了を意味しなかった。
キューでは先頭の1件が処理できない状態になると、その後ろの正常な記事も順番待ちになる。個々の記事が独立していても、処理順序がある以上、先頭の異常は全体へ波及する。今回のように、片側が完了扱いで再処理を行わないと、単純なリトライでは解消しない。後続だけを先に流す運用も、順序や公開条件を崩す可能性がある。
| 工程 | 変更前の判定 | 問題 |
|---|---|---|
| 画像処理 | 最初のマーカーを置換したら完了 | 2個目が残っても処理済みになる |
| 公開キュー | 本文にマーカーが残れば保留 | 画像処理の完了記録と食い違う |
| 修正後 | マーカーが1つだけか共通判定 | 生成前と取り込み前に同じ条件で止める |
判定ロジックを一か所に置く
マーカーの数え方が画像処理、検証、公開キューにそれぞれ実装されていると、修正時に片方だけ変わる恐れがある。そこで、判定と差し込み方法を共通スクリプトに集めた。ドレイン処理と検証入口が同じルールを使うことで、「こちらは1つと数え、あちらは2つと数える」という分岐を避けられる。
動作の考え方は次のようになる。
原稿を受け取る
├─ マーカーが1つ → 画像生成と差し込みへ
└─ 0個または複数 → 理由を出して停止
変更を取り込む前にも、同じ判定を実行
生成後に残ったマーカーを探すだけでは遅い。誤った入力を生成工程へ渡す前に止めれば、不要な画像生成や「処理済みなのに未完了」という状態を作らずに済む。また、取り込み前の検査は、途中で原稿が変更された場合に古い判定結果を信用しないために必要になる。
キューが詰まったときの設計
順番待ちの処理では、失敗を後続へ伝播させないための設計も重要になる。今回の修正で行ったのは、先頭を詰まらせた入力条件を生成前に見つけることだ。一般化すると、キューの各項目に対して「開始条件」「完了条件」「再試行できる条件」を明示し、前後の工程が同じ状態を参照する必要がある。
リトライを設けるだけでは、決定的に不正な入力を解消できない。入力が同じなら、同じ位置で再び止まる。反対に、失敗を記録せず次へ進めると、順序が意味を持つ公開処理では別の不整合につながる。入力を検査して原因を残し、修正可能な状態に置く方が、無限再試行より運用しやすい。
やってみてわかったこと
自動処理の「完了」は、担当スクリプトの終了コードだけでは決められない。次の工程が必要とする状態を実現したかまでを完了条件に含める必要がある。マーカーのような小さな記法でも、生成、差し込み、公開の各工程で意味が異なれば、キュー全体を停止させる。
今回のように判定を共通化し、失敗を早い段階で止めることで、処理済み記録と本文の状態がずれる可能性を減らせる。パイプラインを設計するときは、正常系の処理だけでなく、先頭の1件が不正だったとき何が起きるか、再試行は何を変えるか、後続が安全に進めるかを確かめたい。
更新履歴
- 2026-10-07: 初稿。画像マーカーの判定不一致がキューを停止させた事例を整理。
訂正履歴
なし。