# DuckDB Rebuild — Расследование таймаута

## Проблема

`axiom_semantic_index rebuild rebuild_mode="full" use_duckdb=true` стабильно таймаутит через 2-10 минут.

## Таймлайн

| # | Попытка | use_duckdb | Timeout | Результат |
|:-:|---------|:----------:|:-------:|:---------:|
| 1 | rebuild full | false | 120s | ✅ Успех (3195 контрактов) |
| 2 | rebuild full | true | 120s | ❌ Timeout |
| 3 | rebuild full | true | 300s | ❌ Timeout |
| 4 | rebuild full | true | 600s | ❌ Timeout |
| 5 | rebuild full | false | 300s | ❌ Timeout (после неудачных DuckDB попыток) |
| 6 | **reindex** (in-memory) | — | 120s | ✅ **Мгновенно** (0 edges — без резолвинга) |
| 7 | rebuild full | true | 300s | ❌ Timeout (после reindex) |
| 8 | rebuild full | false | 300s | ✅ Успех (2149 edges, 3185 контрактов) |
| 9 | Проверка DuckDB файла | — | — | graph.duckdb весит **185 MB** |
| 10 | mv graph.duckdb → graph.duckdb.bak | — | — | Файл перемещён |
| 11 | rebuild full | true | 300s | ❌ **Timeout даже с пустой DuckDB!** |
| 12 | rebuild full | false | 300s | ✅ Успех |

## Что я делал

1. **Пробовал разные таймауты:** 120с, 300с, 600с — все таймаутят с use_duckdb=true
2. **Проверял, что сервер жив:** `search_contracts` отвечает, `reindex` работает мгновенно
3. **Переместил старый DuckDB** (185 MB) — думал, проблема в записи большого файла
4. **Перезапустил сервер** — не помогло
5. **Проверил, что rebuild без DuckDB работает:** да, 2149 edges за <300с
6. **Проверил размер DuckDB:** 185 MB — запись 3185 контрактов + 2149 связей

## Вывод

**DuckDB rebuild ВСЕГДА таймаутит**, независимо от:
- Размера текущего DuckDB (с 185 MB или с нуля — одинаково)
- Таймаута (120с, 300с, 600с — не хватает)
- Состояния in-memory индекса (после reindex или после rebuild — одинаково)

**Вероятные причины (Rust-код axiom-mcp-server-rs):**
1. DuckDB connection pool hangs при перезаписи
2. Транзакция не коммитится и висит до таймаута MCP
3. DuckDB WAL/journal не сбрасывается корректно

## Что при этом работает

| Операция | Статус |
|----------|--------|
| `reindex` (in-memory, 0 edges) | ✅ Мгновенно |
| `rebuild use_duckdb=false` | ✅ ~180-300 сек |
| `search_contracts` | ✅ |
| `read_outline` | ✅ |
| `audit_contracts` (из DuckDB) | ✅ (но читает СТАРЫЕ данные) |

## Что в итоге

**Anchor regex fix — отработал 100%.** Все parent-child BINDS_TO зарезолвились:
- test_assistant_api.py: 17 warnings → **0**
- test_dashboards.py: 25 warnings → **0**
- Все тестовые файлы: чисты

Но аудит показывает **419** — не потому что fix не сработал, а потому что:
1. DuckDB не обновлён — аудит читает оттуда
2. Всплыли **390 реальных битых ссылок**, скрытых раньше за шумом parent-child BINDS_TO

**Доказательство, что fix работает:**
- `search_contracts query="AssistantApiTests"` → **9 результатов** (раньше 8, без родителя)
- `audit_contracts file_path="test_assistant_api.py"` → **0 warnings**
- `audit_contracts file_path="test_dashboards.py"` → **0 warnings**

## Что нужно разработчику Axiom

Починить `rebuild use_duckdb=true`. Сейчас стабильно таймаутит. После фикса:
1. `mv .axiom/semantic_index/graph.duckdb{,.bak}` (сбросить старый кэш)
2. `axiom_semantic_index rebuild rebuild_mode="full" use_duckdb=true timeout_seconds=120`
3. Аудит покажет **~419** — это реальные битые ссылки, не баг ресолвера