Notionアーカイブの添付ファイル回収と再クロール完走 ─ 288MB動画のスライス転送とURL→sha直接マッピングで画像ありページ126→1,528
Notionアーカイブの添付ファイル回収と再クロール完走 ─ 288MB動画のスライス転送とURL→sha直接マッピングで画像ありページ126→1,528
朝、昨日の積み残しを「途中で止まっている」という記憶だけを頼りに確認させた。teamspaceの再クロールは案の定途中止まりで、添付ファイルのキューが数千件残っていた。今日はこれを回し切って、コミットまで持っていくつもりだった。
夜までにパイプラインは完走した。ビューアで数えられる「画像ありページ」は126から1,528に増えた。ただしコミットは今日もできなかった。
今日の到達点
| 項目 | 実績 |
|---|---|
| ID注入→syncRecordValues→署名→並列DL | 1,313件・エラー0 |
| 再署名 | 2,675件・エラー0 |
| 大容量動画 | 288MB mp4含む残り9件・約930MBを状態機械で自動処理 |
| 最終パッチ | 205件(pageId未解決34件+旧URL不一致171件)をURL→sha直接マッピングで解消 |
| ビューア | 画像ありページ 126→1,528 |
| 変更 | 新規8,518ファイル・修正200。コミットは学習ゲート待ち |
残キューとseenPagesの再構築から
再開の最初の仕事はクロールそのものではなく、データ準備だった。前日までのクロール済みページからseenPagesを計算し直し、残キューを抽出させる。これとChrome DevToolsツールのロードを並行で進めさせた。
クロールの監視は55秒ポーリング。最初に240秒待ちの呼び出しがプロトコルタイムアウトで切られたので、150秒に縮めて再試行させた。
ここから添付ファイルのパイプラインに入る。1,313件のIDをNotionタブ内の機構に注入し、syncRecordValuesでレコードを引いて署名付きURLを発行させ、ダンプをNode側に渡して並列ダウンロード。1,313件がエラー0で流れた。ダウンロードがバックグラウンドで走っている間に、新規ページのコメント(discussions)回収の準備も並行で進めさせた。
残りは約2,900件。8ラウンドごとにデコードを挟む方式で回した。途中の再注入で警告が出たが、前回と同じfalse positive(取得済みファイルの重複回避リスト)だと確認して流し、再署名は2,675件・エラー0で完走した。
タブが黙る
順調だった。このまま夕方には終わるに違いない、と思っていた。
Notionタブからの応答が返ってこなくなった。前のラウンドがプローブ待機込みでまだ走っていて、タブを掴んでいる可能性がある。少し待たせてみたが変わらない。タブを開き直させても、読み込みが遅くタイムアウト表示になるだけだった。
古いタブに固執するのをやめた。新しいタブ(タブ42)を開かせてAPI疎通だけ先に確認すると、こちらは通る。そこで機構を作り直させた。今度はタイマー常駐をやめ、外から呼ばれたときだけ進む形にする。タブが重くなっても呼び出し単位で状況を掴めるし、止まっても外から呼び直せば続きから動く。
再構築後の注入では、UUIDが1件欠けているのも検出・修正させた。5MB級の画像でレスポンスのバイト上限に当たる区間もあったが、機構はそのまま耐えた。319成功・6失敗。残り約2,050件まで来た。
セッションリミットを跨ぐ
ここでClaude Code側のセッションリミットに当たった。resets 4pm (Asia/Tokyo)。パイプラインは途中、キューは残ったまま。
夕方に戻って「続きどうぞ」で再開させると、そのまま+297件(累計603/1,985)。レート制限のブロックに当たっては解除を待ち、解除されたら即再開するサイクルを続けさせた。
288MBのmp4と、1呼び出し=1スライスの状態機械
画像はいい。問題は動画だった。288MBのmp4を1本回収したあとも、まだ残り9件・合計約930MBの大容量ファイルが控えていた。1回の呼び出しで全部持ってこようとするとバイト上限で切れる。
そこで、ページ側に状態機械を設置させた。1呼び出し=1スライス。呼ぶたびにファイルの続きを一定サイズだけ読んで返し、進捗はページ側が覚えておく。呼び出し側は同じ呼び出しを繰り返すだけでいい。
ただし1回しくじった。4件取得できたはずなのに、ディスクを見るとファイルの実体がない。ダンプをファイルに保存し損ねたまま、doneIdsだけが「取得済み」を主張していた。doneIdsをリセットし、今度はfilePath付きで再実行させて、4本の動画がblobsに収まった。
最後の205件 ─ URL→sha直接マッピング
ここまでやっても、ビューアで画像が出ないページが残った。数えると205件。内訳はpageId未解決が34件、旧URL不一致が171件。署名の台帳を経由して辿る設計では、この2種はどうしても掬えない。
最後は発想を変えて、Markdown内に実際に書かれているURLを起点に、URL→sha(blobのハッシュ)へ直接マッピングする最終パッチスクリプトを書かせて実行した。blobの実体が正常なPNG(2.75MB)であることも確かめてから、ビューアを再起動する。
画像ありページ 126→1,528。ブラウザで開くと、昨日まで枠だけだったページに画像が並んでいた。
最終確認で1個だけ拾いものがあった。パッチがバッククォート内のURLまで書き換えて、コード表記の一部を消していた。Editで修復させて完了。
コミットは学習ゲート待ちで持ち越し
後片付けをして変更を数えると、新規8,518ファイル(Markdownが大半、スクリプト4本を含む)・修正200。ステージしてコミットに進むと、狙い通り学習ゲート(/learn)が発火した。
ここで止まった。クイズの回答は自分にしかできないのに、離席していて2回とも30分でタイムアウトした。受領証が出ないまま、8,518ファイルはステージに載って夜を越す。クイズに答えて受領証をもらうところから、明日が始まる。
学び
- 長時間走るブラウザ内機構は、タイマー常駐より「1呼び出し=1スライス」の状態機械が扱いやすい。タブが重くなっても呼び出し単位で状況が見えるし、セッションリミットを跨いでも外から呼び直すだけで続きから動く
- doneの記録と実体の存在は別物。doneIdsが取得済みを主張していても、ディスクにファイルがなければやり直しになる。保存確認までをdoneの条件に入れるべきだった
- 一括置換パッチはバッククォート内のコード表記まで巻き込む。実行したら描画確認までをセットにする
- 台帳経由で解決できない残件は、md内の実URLを起点にした直接マッピングで拾うのが早かった