# 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