経路を1本に減らしたら、消えていた索引が出てきた — Tursoを外すまでの4本のPR

Valscope(val.codese.net)が読んでいる dev.db の作り方を変えました。 これまでは Iceberg のデータをいったん Turso(クラウド上のSQLite)へ送り、 それを手元へ読み戻して dev.db を組み立てていました。 今回、Turso を経路から完全に外し、Iceberg から dev.db を直接作る形にしています。

やったこと自体は「経路を1本減らした」だけです。 ただ、減らす過程で前から壊れていたものが1つ表に出てきました。その順で書きます。

変えた形

1本目 — 切り替えた(#1418)

Iceberg から dev.db を直接作るようにしました。ここまでは順調です。

2本目 — 索引が1つ消えていた(#1420)

切り替えた結果、db/migrations/ が dev.db に当たらなくなっていました。 経路を変えたときに、マイグレーションを適用する段が経路から落ちていたのです。

表に出たのは、地図ページ(/map)のクエリでした。 索引 027 が無い状態になっており、インデックスを使うはずのクエリが テーブル全走査(SCAN)へ退行していました。

**画面はちゃんと出ます。**ただ遅い。エラーも出ない。 「動いているが、設計した速さでは動いていない」という壊れ方で、 これは切り替えのPRを見ているだけでは気づけませんでした。

適用経路を戻して直しています。

3本目 — Turso を外し切った(#1431)

ここで「もう Turso は要らない」と判断し、残っていたものを全部落としました。

• export_to_turso.py を export_to_devdb.py へ改名。 Turso のHTTP経路(_get_http_url / _execute_http / _upsert_batch / _get_valid_codes_remote)と local 分岐、HTTP往復のためだけにあった asyncio を削除して同期化した
• 旧 export_to_devdb.py(7テーブルだけの部分実装)は名前を譲って削除
• sync-dev-db-from-turso.mjs が担っていたスキーマ整合を移設。 マイグレーション適用は夜間バッチの apply_migration.py --local --all、 米国系テーブルの CREATE は app/external/us_financials_store.SCHEMA へ
• 夜間バッチから STOCK_APP_TURSO_EXPORT と Turso エクスポートのステップを削除
• verify_export_parity.py --source turso と、送信先が消えた run_throttled_turso_backfill.sh も削除

2本目で踏んだ問題は、手で書いた MIGRATIONS 配列が原因でした。 新しいマイグレーションを足しても、配列に書き足さなければ当たらない。 歯抜けが黙って発生します。移設によってこの配列自体が消えたので、 同じ穴はもう掘れません。

もう1つ、dev.db に対象テーブルが無い状態でエクスポートが走り、 0件のまま静かに完了する破損(Issue #1412)を防ぐため、 開始時にテーブルの存在を検査して、無ければ異常終了するようにしました。

4本目 — 書いた説明のほうが間違っていた(#1432)

設計ドキュメントに「まっさらな dev.db からは中身を再構成できない」と書いていました。 これが言い過ぎでした。数え直すと、

• Iceberg が正本の13テーブル → apply_migration.py --all と export_to_devdb.py の2コマンドで戻る
• 残る3テーブル → bootstrap_us_financials.py と run_rolling_backtest_export.py で再生成できる

つまり全部戻せます。 ただし実運用で壊れたときの最短復旧は、Blob に置いてあるスナップショットを戻すことです。 「戻せる」と「戻すのが速い」は別なので、両方書き直しました。

残ったもの

今回いちばん効いたのは、経路を減らしたこと自体ではなく、 減らす過程で経路の途中の段を1つずつ数え直したことでした。 2本目の索引欠落は、経路を触らなければあと何ヶ月も気づかないままだったはずです。

同じことをやる人向けに、手順と踏んだ挙動を dev.dbを1本の経路で作るへまとめました。