capture_submissions

投げた瞬間に「誰のために投げたか」を残すための表です。

    // BrowserHive のタスク id が、結果の報告へ戻る join の鍵になる。
    .addColumn("task_id", "uuid", (col) => col.primaryKey())
    .addColumn("correlation_id", "text")
    .addColumn("org_id", "text", (col) => col.notNull())
    // それを求めた利用者。居た場合に限る。人ではなく組織に属する定期実行では NULL。
    .addColumn("submitted_by", "text")
    .addColumn("submitted_at", "timestamptz", (col) => col.notNull().defaultTo(sql`now()`))

取り込みごとの結果 manifest の在り処は 014 で足しました。

    // bucket を除いた鍵。報告が運んだ場所をそのまま —— 台帳は組まない。
    .addColumn("manifest_key", "text")
    // 書けなかった理由、または台帳には読めない場所だった理由。
    .addColumn("manifest_error", "text")

なぜ必要か

BrowserHive に「組織」という概念はありません。 取り込みを投げるとき capture-ledger は URL と設定だけを渡し、返ってくるのは taskId です。

後から bucket の .result.json を拾って台帳を埋めるとき、その manifest には 組織を特定するものが何も入っていません。だから投げた瞬間にここへ記録しておくのが唯一の出どころになります。

capture-ledger が知っている        BrowserHive が知っている
─────────────────          ─────────────────────
capture_targets.org_id ──┐      taskId
                         │      成果物の場所
                         └──→   （組織は知らない）
              capture_submissions
              task_id → org_id の対応

この行が無いと、reconciler は「このアーカイブは誰のものか」を言えません。

書かれ方

段の報告を受ける handler（src/api/crawls.ts）が、報告のうち taskId を持つページすべて（失敗も含む）について 1 行ずつ書きます。その取り込みの .result.json が書かれた場所も一緒です。

submitted.map((r): Insertable<CaptureSubmissionsTable> => ({
  taskId: r.taskId,
  correlationId: r.correlationId ?? crawlId,
  orgId: crawl.orgId,
  submittedBy: crawl.requestedBy,
  manifestKey: manifests.get(r.taskId)?.key ?? null,
  manifestError: manifests.get(r.taskId)?.error ?? null,
}));

capture-ledger は manifest の鍵を組みません。 BrowserHive（または受け口）は Capture の応答で manifest を書いた場所を答え、Windmill の flow がそれを manifestLocation として運びます。handler は、その場所が設定の bucket の中なら鍵の部分を残します。manifest を書けなかった取り込みは代わりに manifestError で報告され、その理由がここに入ります。別の bucket や s3:// でない場所も理由として入ります —— 読み先を報告する側に選ばせないためです。

taskId を持つのに、この 2 つのちょうど 1 つを持たない報告は 400 で断ります。受け付けると、読みに行く先の無い取り込みが残るからです。

taskId は BrowserHive が採番し、使い回されることはありませんが、段の報告が送り直されることはあるので onConflict … doNothing() を置いています。

読まれ方

reconcile.ts が、manifest_key を持ち、まだアーカイブの無い行を引きます。

manifest_key を持ち、archives に行の無い capture_submissions の行
  → GetObject(manifest_key)
  → archives に登録し、その org_id と submitted_by で tuple を積む

列の要点

列	要点
`task_id`	主キー。 BrowserHive が採番したもので、結果の報告へ戻る join の鍵
`org_id`	`not null`。この表が在る理由そのもの
`submitted_by`	それを求めた利用者。人ではなく組織に属する定期実行では NULL
`submitted_at`	`now()` 既定
`manifest_key`	その取り込みの `.result.json` の在り処（bucket を除く）。報告のまま。`manifest_error` が在るときと、`014` より前の行では NULL
`manifest_error`	台帳が読める manifest が無い理由。書けなかったか、報告された場所が設定の bucket の外