ノードを建て終えて、初めて pm2 logs を流したとき、最初に目に入るのは「赤い文字」かもしれません。ERROR。WARN。何やら不穏なメッセージが、画面の上から下へ流れ続けています。
「もしかして、何か間違えたのか」「自分のノードは、壊れているのか」── そう思って、慌ててインストールをやり直そうとした人もいるかもしれません。
でも、落ち着いてほしい。
森に入ったばかりのハンターが最初に学ぶのは、鳴き声を聴き分けることです。森には常に音があります。鳥のさえずり、葉のこすれる音、遠くの獣の足音。そのすべてが「危険」ではありません。危険な音と、ただの森のざわめきを聴き分けられるようになって初めて、ハンターは森の中で静かに眠れるのです。
CAWノードの稼働初期にも、同じことが言えます。流れるエラーのほとんどは、慌てる必要のないものです。だが、なかにはすぐ対応すべきものもあります。この記事は、その聴き分け方の手引きです。
重要度の見方
すぐに対応が必要。放置するとノードが正しく機能しない。
様子を見つつ、必要なら対応。同期完了後も続くなら手を打つ。
初期同期中に頻出するが、放置で問題ない。開発側の課題か、順序の問題。
★★★ 緊急 ─ すぐに対応すべきエラー
query exceeds max block range 2000
Error: query exceeds max block range 2000
何が起きているかCAWクライアントは過去のブロックをまとめて取得する際、デフォルトで「一度に10,000ブロック」を要求します。しかし多くのRPCプロバイダ(特に無料枠)は、一度のクエリで取得できるブロック数を2,000ブロックまでに制限しています。結果、クエリが拒否され、過去ブロックの同期が一切進みません。
対応ソースコードの定数を書き換えます。
/var/www/(あなたのドメイン)/client/src/services/RawEventsGatherer/listenForRawEvents.ts // 修正前 chunkBlocks = 10_000 // 修正後 chunkBlocks = 1500
修正後、ビルドし直して再起動すれば、同期が進み始めます。このバグは現時点(2026年6月)で公式 install.sh に残っている既知の問題で、新規に建てた人はほぼ全員が踏みます。覚えておいて損はありません。
★★ 注意 ─ 観察すべきエラー
P2028: Transaction API error
PrismaClientKnownRequestError: Transaction API error: Transaction not found. Code: P2028
何が起きているかPrisma(データベースを扱うライブラリ)がトランザクションを開始しようとして、規定時間内に取得できなかった状態です。初期同期中はブロック処理とユーザーデータ取り込みが同時並行で走るため、瞬間的にデータベース接続プールが詰まります。これがタイムアウトの正体です。
判断初期同期中に出る → 静観。同期が進めば自然に消えます。同期完了後も続く → 接続プールが恒常的に詰まっているので、DATABASE_URL に ?connection_limit=30 を追加して再起動。
pm2 logs caw-server-(ドメイン) --lines 2000 --nostream | grep -c "P2028"
数日経って件数が減っていれば、健全な経過です。
registered: false, instanceId: null が長く続く
何が起きているかノードはネットワークに接続できているが、まだオンチェーンに登録されていない状態です。同期がある程度進めば、自動的に登録試行が行われます。
判断同期中 → 静観。ただし、同期が進んでも数時間〜半日 false のまま動かない場合は、別の原因が隠れていることがあります。とくにL1用RPCのタイムアウトが原因で登録が止まるケースについては、別記事『闇の中で躓いた時 ─ ノード構築トラブルシューティング』で実例を詳しく追っているので、あわせて読んでみてください。
★ 静観 ─ 放置でいいエラー
Domain processing skipped for unknown caw
[WARN] Domain processing skipped for unknown caw: 0x...
何が起きているかあるアクション(リプライ、いいね等)が指す元の投稿が、まだノードのデータベースに取り込まれていない状態で処理されようとした、順序の問題です。過去のブロックを古い方から取り込んでいくため、ときに「Aさんの投稿に対するBさんのリプライ」のような関連イベントが、本体より先に検知されることがあります。その時点ではAさんの投稿はまだデータベースにないため、リプライ先が「unknown」になります。
対応放置でよい。同期が進めば、いずれAさんの投稿も取り込まれ、整合性は取れます。
Insufficient CAW balance – ledger drift?
[WARN] Insufficient CAW balance - ledger drift?
何が起きているか上と同じく順序問題です。CAW残高の変動イベントが、別のイベントより先に処理されて、計算上「残高が足りない」状態に見えています。
対応放置。同期完了時には台帳は正しく揃います。
Failed to create follow notification (42P10)
PrismaClientKnownRequestError: ... constraint matching the ON CONFLICT specification Code: 42P10
何が起きているか通知テーブルに対するSQLのうち、ON CONFLICT 句が参照しているユニーク制約がデータベース側に存在しないため、通知の作成に失敗しています。CAW開発側のスキーマ課題です。
フォロー通知やいいね通知が、相手に届かない場合がある
フォロー・いいね自体はオンチェーンに正常に記録される
投稿・閲覧・その他の基本機能は動く
対応放置。開発側の修正を待ちます。自前でスキーマを書き換えると、将来のアップデートと衝突する可能性があります。
ログを読む心構え
最初は、流れるすべてのERRORを「ノードが壊れている証拠」のように感じるかもしれません。だが、CAWクライアントはマルチスレッドで膨大なオンチェーンデータを並行処理しています。設計上、「ある瞬間に整合が取れていない状態」が一定割合で必ず発生します。それを律儀に WARN や ERROR として出力しているだけで、時間が経てば整合は取れていきます。
ハンターは森の音すべてに反応していたら、消耗してしまいます。
── その聴き分けの精度こそが、長くノードを運営し続けるための、地味だが本質的なスキルだ。
そして、もしこの記事に書かれていない見慣れないエラーが流れたら、まずは調べてみてください。わからないことは、他のハンターに聞くのもよし。森は、独りで歩くものではありません。
付録：便利なログ確認コマンド
特定のエラーが何件出ているか数える
pm2 logs caw-server-(ドメイン) --lines 2000 --nostream | grep -c "エラー文字列"
直近の特定エラーを、前後の文脈ごと見る
pm2 logs caw-server-(ドメイン) --lines 500 --nostream | grep -B 2 -A 5 "エラー文字列"
リアルタイムでログを流しながら、エラーだけ抽出
pm2 logs caw-server-(ドメイン) | grep -iE "error|warn"
第3話で無事ノードを起動させたあなたへ。まずはこのログの森を歩く心構えを整えてほしい。
森の音を聴き分けられるようになって、はじめて夜に眠れるのだから。
