FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
記事本文bundleとfresh実行基盤を統合する
取得先ごとに本文をまとめ、過去contextを持たない日次編集を安全に開始する
目的
ニュース取得先ごとに異なる時刻で編集を行い、一つの取得先の障害がほかの取得先を止めない実行単位が必要だった。
複数記事の本文を安全に一つへまとめつつ、同じ取得先・同じ日に二つ目のfresh rootを始めない復旧境界が必要だった。
実装
公開HTTPS記事からmain textだけを抽出し、同じ取得先の複数記事を一つのNewsPacketへまとめるbundleを作った。manifest、本文、path、hash、symlink、取得先の純粋性を検査してから、過去会話や過去記事をcontextへ渡さない専用runtimeでfresh実行する。
- 取得先ごとのJST正時で対象を選び、同時刻は決定的な順序で直列実行する。
- 一つの取得先と日付につき一つのpacket、fresh root、draftに限定する。
- 一つの取得先が失敗してもほかを継続し、当日分だけをcatch-upする。
- pending再送を新規実行より先に行い、process停止後も二つ目のrootを作らない。
- 取得先単位の新形式と、過去形式のpending再送laneを分離する。
投入結果は取得先IDを含む厳密な応答として検証し、欠落、不一致、非canonical値、余分なfieldがあればsubmittedへ進めずpendingを維持する。
一次Commitで追加されたpacket artifactのserializationと、write後の内容を事前確定digestへ照合する境界を示す。schema、exact bytes、digest、lengthを一つのartifactへ固定している。
図を描画しています…
確認したこと
確認結果
17件のscript testと21のtest fileに含まれる393件のtest、typecheckが通った。
schedule、順序、failure isolation、catch-up、pending先行、source purity、crash recoveryを確認した。
投入応答の取得先IDが一致する場合だけ成功し、欠落・誤値・大文字・余分なfield・不正形式をfail closedにできた。
通常の実行環境と過去形式のpending再送挙動は維持された。
bundleとfresh実行基盤は対象へ反映された。定期serviceの起動、live実行、本番投入はcutoff時点で未実施だった。
完了とした根拠
本文bundle、source/day schedule、fresh runtime、重複root防止、pending先行復旧、strict acknowledgementを実装し、393件のtestとscript検証を通過したことをもって完了とした。