fix

Author: anton.voskresensky

ARCHITECTURE.md

@@ -80,7 +80,7 @@ osctl/
    - Показываем план создания снапшотов с указанием репозитория для каждой группы
 6. **Создание снапшотов (параллельно, с ограничением слотов)**:
    - Для всех групп формируем список задач `SnapshotTask` с полями: имя снапшота, список индексов, репозиторий, дата и расчетный размер (`Size`), который используется для приоритизации.
-   - Задачи сортируются по размеру **по убыванию** (большие снапшоты первыми), чтобы сначала снимать “жирные” индексы.
+   - Задачи сортируются по размеру **по убыванию** (большие снапшоты первыми).
    - Для всех задач запускается worker‑pool через `CreateSnapshotsInParallel`:
      - Количество одновременно работающих горутин ограничено конфигом `max-concurrent-snapshots` (по умолчанию 3).
      - Каждая горутина (worker) последовательно берет задачи из общего канала и вызывает `CreateSnapshotWithRetry`, передавая свой `workerID` для логов.
@@ -99,9 +99,9 @@ osctl/
    - **Проверка существующего снапшота прямо перед созданием**:
      - После ожидания слота, но до вызова `CreateSnapshot`, `CreateSnapshotWithRetry` еще раз вызывает `CheckSnapshotStateInRepo` для конкретного снапшота:
        - Если снапшот уже в состоянии `SUCCESS` — создание пропускается, задача считается выполненной.
-       - Если снапшот уже есть в другом состоянии (`IN_PROGRESS`/`FAILED`/`PARTIAL` и т.п.) — вызов `CreateSnapshot` пропускается, дальше запускается только мониторинг этого существующего снапшота (это устраняет 400 `invalid_snapshot_name_exception` и гонки между разными процессами).
-   - **Проверка статуса и шарды с ошибками**:
-     - После старта или при “подхвате” уже существующего снапшота `CreateSnapshotWithRetry` опрашивает его статус через `GET /_snapshot/{repo}/*{today}*` (через `GetSnapshots`) с таймаутом видимости 15 минут.
+       - Если снапшот уже есть в другом состоянии (`IN_PROGRESS`/`FAILED`/`PARTIAL` и т.п.) — вызов `CreateSnapshot` пропускается, дальше запускается только мониторинг этого существующего снапшота (иначе возникает рейс кондишен).
+   - **Проверка статуса**:
+     - После старта `CreateSnapshotWithRetry` опрашивает статус через `GET /_snapshot/{repo}/*{today}*` (через `GetSnapshots`) с таймаутом видимости 15 минут.
      - Если состояние `IN_PROGRESS`, дополнительно вызывается `GetSnapshotStatusDetail` (`GET /_snapshot/{repo}/{snapshot}/_status`).
      - Если в детальном статусе `shards_stats.failed > 0`:
        - Снапшот сразу считается невалидным, удаляется через `DeleteSnapshotsWithRetry`.
@@ -127,12 +127,6 @@ osctl/
 - Поддерживает переопределение репозитория через `Repository` в конфиге индекса
 - Использует общий лимит параллельных снапшотов `max-concurrent-snapshots` (CLI/конфиг), по умолчанию 3
 
-#### Обновления (декабрь 2025)
-
-- Перед каждым фактическим `CreateSnapshot` внутри `CreateSnapshotWithRetry` выполняется дополнительная проверка через `CheckSnapshotStateInRepo`:
-  - Если снапшот уже в состоянии `SUCCESS` — создание пропускается, задача считается выполненной.
-  - Если снапшот уже есть в другом состоянии (`IN_PROGRESS`/`FAILED`/`PARTIAL` и т.п.) — мы не вызываем создание, а просто начинаем мониторить существующий снапшот (это устраняет 400 `invalid_snapshot_name_exception` и гонки между процессами).
-
 ### 2. **snapshot-manual** - Ручное создание снапшотов
 
 **Алгоритм:**
@@ -619,7 +613,7 @@ osctl/
    - Извлекаем базовый паттерн через первую группу захвата regex
    - Формируем паттерн: `{base}-*`
    - Удаляем дубликаты
-4. **Получение существующих patterns**: `GET /{tenant_index}/_search?q=type:index-pattern` из `.kibana` (без `.kibana*`).
+4. **Получение существующих patterns**: `GET /{tenant_index}/_search?q=type:index-pattern` из `.kibana`.
 5. **Создание недостающих patterns**: Для каждого отсутствующего паттерна создаем через `POST /{tenant_index}/_doc/index-pattern:{uuid}`
 6. **Создание extracted_* pattern** (если `--indexpatterns-recoverer-enabled`):
    - Создаем паттерн `extracted_*` с ссылкой на data-source через `references`