tf_provider/HISTORY/OPUS/2026-07-07_subresource_duplicate_exist_bug.md

2026-07-07 — Opus analysis: duplicate/exist subresource adopt

Контекст

После фикса mutex (v5.0.63) при параллельном создании subresource'ов pg_user_5 упал:

«Операция вернула duplicate/exist, но объект не найден в state_out»

Корневая причина (найдена)

PostgreSQL (svc 90), state_out инстанса НЕ содержит databases и users вообще. Артефакт: artifacts/output_inventory/running_suspended_output_fields_for_docs.json

• PG out_paths: externalConnect, internalConnect, monitoring — ни баз, ни юзеров.

Для Kafka (svc 116) ключи есть, но называются kafkaUsers и kafkaTopics (не users/topics).

Почему adopt subresource'а не работает

subresource_guard.go:

• SubresourceListKey("database") → эвристика name+"s" → "databases"
• FindSubresourceInStateOut → details.RawOut["databases"] → ключа нет → known=false
• Create-обработка duplicate требует known && found, но known=false всегда
• → падает в «Нарушена консистентность» всегда

Для основных ресурсов adopt работает через client.FindInstanceByDisplayName — реальный запрос к API инстансов. Для subresource'ов такого API нет.

Дополнительные вопросы для Опуса

1. Есть ли в API отдельные эндпоинты list_databases/list_users для PostgreSQL, которые можно дёргать вместо парсинга state_out?

2. SubresourceListKey/SubresourceIdentityKey — эвристики name+"s" и special-map на 2 сервиса. Нужен явный маппинг из YAML-метаданных (реальные ключи: kafkaUsers, kafkaTopics).

3. При known=false (ключ не найден в state_out) — должен ли adopt доверять ошибке already exists от API и усыновлять без подтверждения? Сейчас падает в «Нарушена консистентность».

4. IsSubresourceAlreadyExistsError — достаточно ли маркеров уже существует/already exists/duplicate/conflict? Что если API вернёт HTTP 409 без текста или другую формулировку?

Дата: 2026-07-07