FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
AIタレント編集部を一つの論理roomへ統合する
取得先ごとのfresh rootを同じ編集空間へ集め、日次実行と履歴の境界を固定する
目的
ニュース取得先ごとに独立して始まる編集作業を、日をまたいでも同じ編集部の履歴として扱う仕組みが必要だった。
取得先ごとの実行時刻と焦点を管理しながら、重複記事、別取得先の混在、履歴pagination中の流入を防ぐ必要があった。
実装
DB生成UUIDと正式名を持つ一つの論理roomを設け、各取得先から日ごとに始まるfresh rootと子孫threadをmembershipで集約した。管理画面では取得先ごとのJST正時、編集時の焦点、有効・無効を設定できる。
- 同じ取得先の複数Feed itemを一つのpacket、一つのfresh root、一つのdraftへまとめる。
- 一つの取得先とJST日につきroot、run、articleを高々一つにし、別取得先とのidentity衝突を拒否する。
- 無効化した取得先の新規実行を止めつつ、無効化前に固定済みのpending処理は同じidentityで完了可能にする。
- room履歴のmembershipと時点を固定し、署名付きcursorでroot、thread、messageを欠落や重複なく辿る。
- 公開記事の初回公開時刻を不変の順序キーとし、非公開化された記事を安全側で即時に隠す。
既存の送信形式とsource情報を持たない過去データは互換対象として残し、browserへsecretや広いdatabase権限を渡さない境界も維持した。
一次CommitのOffice mapperから、room membershipをowner、project、root identityで照合し、複数roomへ曖昧に結び付くrootを表示しない境界を確認した。
図を描画しています…
確認したこと
確認結果
90件のapplication test、typecheck、lint、applicationとWorkerのbuildが通った。
fresh database reset、database lint、schema・権限・legacy互換のsmoke testが通った。
121 root、1,201 thread、2,401 messageと251 articleのcursor走査で欠落・重複防止を確認した。
1,000件を超えるrelation、50件を超えるstatus集計、並行する送信とmembership登録、完全・部分rollbackを確認した。
論理room、取得先設定、履歴境界は対象へ反映された。本番でのmigration適用、定期実行、live runはcutoff時点で未実施だった。
完了とした根拠
取得先単位のidentity、論理room membership、管理設定、署名付き履歴cursor、互換・権限境界を実装し、大量データ、並行処理、rollbackを含む検証が通ったことをもって完了とした。