背景
@d-zero/beholder に ScrapeResult.consoleLogs(ConsoleLogEntry[])が追加された(d-zero-dev/tools#925、dev マージ済み)。ページが出力する console メッセージ(全type)と、未捕捉例外・未処理の Promise rejection(type: 'pageerror'、スタックトレース付き)を、内部ページのみ対象に収集する。
即座に必要な対応(beholderアップグレード時の型エラー)
ScrapeResult は consoleLogs が必須フィールドになったため、以下のリテラル構築箇所が型チェックで落ちる:
packages/@nitpicker/crawler/src/crawler/crawler.ts の #scrapePage(994行目〜)内、{ type: 'success', pageData: ..., resources: [] } 形のリテラル4箇所(1038 / 1240 / 1249 / 1261行目付近)→ consoleLogs: [] を追加
crawler.spec.ts / should-discard-predicted.spec.ts 内の ScrapeResult リテラル(テストフィクスチャ)複数箇所も同様
本来やりたいこと(テーブル新設)
resources の既存パターン
- beholder:
ScrapeResult.resources: ResourceEntry[] を戻り値で一括返却(DBを知らない)
crawler.ts: #handleResources(382行目)が配列をループし、crawlerレベルの response/responseReferrers イベントをper-item emit
- archive層:
insert-resource.ts が resource_items(URL/blob重複排除・upsert-merge)+ resource_ref_edges(page_id×resource_idの多対多、参照カウント)に書き込む
consoleLogs では単純化できる点
console ログは「複数ページから共有参照されるリソース」ではなく「そのページ・その瞬間限りのイベント」なので、resource_items/resource_ref_edges のような重複排除・upsert-merge・多対多テーブルは不要。anchor_edges よりもさらに単純な「page_id を直接持つフラットなイベントテーブル」で十分と考えられる。
スキーマ案(例、既存の text_refs/url_refs 等の正規化慣習に合わせて要調整):
CREATE TABLE IF NOT EXISTS console_log_items (
id INTEGER PRIMARY KEY AUTOINCREMENT,
page_id INTEGER NOT NULL REFERENCES content_items(id),
type TEXT NOT NULL, -- ConsoleMessageType | 'pageerror'
text_id INTEGER REFERENCES text_refs(id),
args_json TEXT, -- JSON.stringify(entry.args)、失敗時はNULL
location_url_id INTEGER REFERENCES url_refs(id),
location_line INTEGER,
location_column INTEGER,
stack_text_id INTEGER REFERENCES text_refs(id),
ts INTEGER NOT NULL
)
配線
crawler.ts に #handleConsoleLogs(result.consoleLogs, ...) を新設(#handleResources と同型、this.emit('consoleLog', entry) をper-itemでemit)
- archive層に
insert-console-log.ts(insert-resource.ts 相当。ただしconsoleログは重複排除不要な単純 INSERT)を新設
決定済みの設計判断(beholder側の議論より)
- 全 console type(log/debug/info/warn/error等)が収集対象。error/warning/infoに絞らなかった理由: 精緻な記録を優先
pageerror(未捕捉例外)は別typeとして区別。argsは空、stackのみ保持
- 収集は内部ページのみ(
isExternal: false)
- 本文は
text() と args()(jsonValue()展開、失敗時はundefined)の両方を保持
参照
背景
@d-zero/beholderにScrapeResult.consoleLogs(ConsoleLogEntry[])が追加された(d-zero-dev/tools#925、devマージ済み)。ページが出力する console メッセージ(全type)と、未捕捉例外・未処理の Promise rejection(type: 'pageerror'、スタックトレース付き)を、内部ページのみ対象に収集する。即座に必要な対応(beholderアップグレード時の型エラー)
ScrapeResultはconsoleLogsが必須フィールドになったため、以下のリテラル構築箇所が型チェックで落ちる:packages/@nitpicker/crawler/src/crawler/crawler.tsの#scrapePage(994行目〜)内、{ type: 'success', pageData: ..., resources: [] }形のリテラル4箇所(1038 / 1240 / 1249 / 1261行目付近)→consoleLogs: []を追加crawler.spec.ts/should-discard-predicted.spec.ts内のScrapeResultリテラル(テストフィクスチャ)複数箇所も同様本来やりたいこと(テーブル新設)
resourcesの既存パターンScrapeResult.resources: ResourceEntry[]を戻り値で一括返却(DBを知らない)crawler.ts:#handleResources(382行目)が配列をループし、crawlerレベルのresponse/responseReferrersイベントをper-item emitinsert-resource.tsがresource_items(URL/blob重複排除・upsert-merge)+resource_ref_edges(page_id×resource_idの多対多、参照カウント)に書き込むconsoleLogs では単純化できる点
console ログは「複数ページから共有参照されるリソース」ではなく「そのページ・その瞬間限りのイベント」なので、
resource_items/resource_ref_edgesのような重複排除・upsert-merge・多対多テーブルは不要。anchor_edgesよりもさらに単純な「page_idを直接持つフラットなイベントテーブル」で十分と考えられる。スキーマ案(例、既存の
text_refs/url_refs等の正規化慣習に合わせて要調整):配線
crawler.tsに#handleConsoleLogs(result.consoleLogs, ...)を新設(#handleResourcesと同型、this.emit('consoleLog', entry)をper-itemでemit)insert-console-log.ts(insert-resource.ts相当。ただしconsoleログは重複排除不要な単純 INSERT)を新設決定済みの設計判断(beholder側の議論より)
pageerror(未捕捉例外)は別typeとして区別。argsは空、stackのみ保持isExternal: false)text()とargs()(jsonValue()展開、失敗時はundefined)の両方を保持参照
packages/@d-zero/beholder/src/types.tsのConsoleLogEntry