FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Editorialのdatabase実行基盤を追加する
6 table、human-admin／Runner RPC、global FIFOでdraft生成前の状態を管理する
目的
確定したEditorial設計を実行するには、Channel設定、Feed取得、記事screening、人による判断、Codex生成を同じ状態機械で管理し、管理者とRunnerの権限を分離するdatabase基盤が必要だった。
raw tableをclientへ公開せず、目的別RPCだけでscheduled実行、記事判断、生成queue、failure、fresh rerunを進められるlocal database contractを実装することを目指した。
実装
Editorial migrationにChannels、Feeds、Runs、Run Executions、Execution Feeds、Run Itemsの6 tableを追加した。各tableはRLSを有効にしてraw grantを外し、statusとfailure／stop／draft fieldの整合をconstraintで固定した。
human administrator向けRPCはChannel／Feed管理、Execution参照、記事decision、Generate、Stop、fresh rerunを担当する。Runner向けRPCはschedule、collection開始・結果記録・終了、global FIFO dequeue、root Thread記録、draft完了、failure記録を担当し、principal種別を相互に拒否する。
同じChannelと対象日には一つのRunだけを作り、scheduled呼出しを冪等にした。生成待ちはqueued timeとIDでglobal FIFO dequeueし、失敗・停止したExecutionの再実行は元の記録を残して新しいexecution numberを作る。
screeningがindeterminateの記事は承認不可とし、全記事decisionが揃い、1件以上がapprovedの場合だけ生成待ちへ進む。生成中はthread.startedのroot IDをdraft payloadと分けて記録し、root同期より先に保存できるようThread tableへの外部keyを持たせない。
製品default fixtureへ単一のEditorial Desk Roomを追加した。これはdummy Roomではなく、後続のRunnerが生成rootを登録する安定した製品dataとして最小fixtureから投入する。
図を描画しています…
確認したこと
確認結果
6 tableすべてでRLSとraw access拒否が定義され、anonymous、human administrator、RunnerのRPC境界が分離された。
45件のpgTAP assertionがChannel活性、schedule冪等性、screening判断、global FIFO、draft保存、failureとfresh rerunを網羅した。
indeterminate記事のApprove拒否と、失敗記録を残した新しいExecutionの作成がdatabase transactionで固定された。
cutoff時点でdatabase実行基盤と製品default Roomは対象へ反映された。Feed取得、screening provider、Codex実行は次の活動範囲である。
完了とした根拠
6 table、constraint、目的別RPC、principal分離、schedule冪等性、global FIFO、human decision、fresh rerun、default RoomがmigrationとpgTAPで同じcontractを表したことを完了基準とした。