HTTP 200、messagesImported: 3。3件の本文もIDも戻っている。それでも、返信先の情報だけが消えるケースを再現しました。
AI運用の開発プロジェクト aichance で、2026年10月16日に行ったローカル検証です。対象は WA-archiverの固定コミット（package 1.1.0-beta.1）、サーバーSQLiteモード。検証対象の元ファイル222件が固定版と一致することを確認し、アプリを変更せず、架空のテキストメッセージだけを使いました。作者本人による実行報告ではありません。
復元前と復元後
親メッセージ、通常メッセージ、親への返信の3件を用意します。返信は通常のメッセージ作成APIへ replyToId を渡して作り、保存後のAPIと画面の両方で、親への参照が成立していることを先に確認しました。
バックアップ前には、返信本文の上に引用が表示されています。
実際の Settings → Download backup (.json) で得た1,783bytesを、別に作った空のSQLite DBへ Restore from backup からそのまま渡し、再読み込みします。
| 比較対象 | バックアップ前 | 復元・再読み込み後 |
|---|---|---|
| メッセージ件数 | 3 | 3 |
ID・本文・日時など、replyTo以外の全選択項目 |
保存値 | 一致 |
返信のreplyTo
|
親のID・送信者・本文・種別を持つオブジェクト | null |
| 返信内の親メッセージの引用 | 表示 | 非表示 |
通常のメッセージ取得APIが返す3レコードを全項目比較すると、差分は返信1件の replyTo だけでした。通常項目が残ったことを確認する対照と、関係が残ったことを確認する検査を分けたため、「全部壊れた」という曖昧な結果にもなりません。
エクスポート同士を比べると見逃す
この固定版では、バックアップのGETが replyToId を出力せず、復元するPOSTもその関係を保存していませんでした。
つまり、エクスポートしたJSONと、復元後にもう一度エクスポートしたJSONの共通項目だけを比べると、どちらにも返信先が存在しません。比較対象から最初に落ちた項目は、一致しているように見えてしまいます。
今回は、返信関係を解決して返す通常のメッセージAPIを観測に使いました。画面の引用表示も別に確認しています。検査対象のエクスポーターだけに、何を比較するかを決めさせないことがポイントでした。
ブラウザを新しくするだけではDBは空にならない
このアプリの今回のモードはサーバーSQLiteです。ブラウザコンテキストを新しくしても、同じサーバーを使えばDBは共有されたままです。
検査コードは送出元・復元先に別々の新規SQLiteファイルを作り、子プロセスごとにDBパスを指定しました。復元先は事前にチャット一覧が空、検証チャットの取得が404であることを確認しています。その後、実際にダウンロードしたバイト列を復元UIへ渡しました。JSONの作り直しや、復元後のレコードの補修は行っていません。
画面が自動生成する空のSaved Messagesチャットは重複として1件スキップされ、検証用チャット1件・メッセージ3件が取り込まれました。成功件数と、守りたい値の一致は別々に確認します。
普通の保存検査は2件ともPASSしていた
App Crash Lab 0.10.0 で、このアプリの次の2件はPASSしています。
- 保存後に再読み込みしても、選択した全メッセージDTOが変わらない。
- 壊れたJSONをHTTP400で拒否した後も、保存値が変わらない。
生成した通常のPlaywrightも、別実行で2件PASSしました。CLIと生成テストは同じプロトコルを共有しており、独立した検査アルゴリズムではありません。
バックアップは別の経路を通ります。そこで実ファイルの復元まで追加すると、今回の返信関係の欠落が見つかりました。
なお、App Crash Lab 0.10 の組み込みバックアップ検査はブラウザ内の保存レコードが対象です。今回のサーバーDBの往復は、別のPlaywright補助コードで実行しています。組み込み機能でサーバーSQLiteを検査できた、という報告ではありません。
自分のアプリへ持ち帰るなら
- 意味のある親子・参照・依存関係を通常の操作で作り、保存できたことを確認する。
- 復元先を、実際の保存先の単位で空にする。新しいブラウザと新しいDBを区別する。
- アプリが出した実ファイルを、そのまま通常の復元UIへ渡す。
- エクスポート形式だけに依存しない観測経路で、選択した完全レコードと関係を比較する。
再実行用キット・通常検査のJSON・元のバックアップ・実測結果をGitHubで公開しています。検証済みの起動手順はREADMEにあります。サーバー起動も管理する補助コードはmacOS/Linux向けで、実測はmacOS・Node22.16.0です。自身のアプリへ導入する場合は、セレクターと観測項目を実際の保存仕様に合わせてください。
対象は今回の3件の架空テキストと引用表示です。Android、端末内SQLite/OPFS、メディア、予約メッセージ、DB全体の忠実な復元は別の検査が必要です。
次のリリース前に見返したい方は、必要ならリポジトリをStarで保存しておいてください。自分のアプリで試した結果や導入で詰まった点も、Issueで受け付けています。