# Резюме сессии: VDC create-flow, диалог с Opus и правка fallback (2026-09-21)

## 1. Контекст задачи
- Цель: довести до рабочего состояния создание `nubes_vc_vdc` в `FullPipe`.
- Симптом: при создании VDC провайдер падал на `GET /instanceOperations/{opUid}?fields=cfsParams` с HTTP 500.
- В ходе разбора было подтверждено, что обычные сервисы через тот же провайдер работали, а VDC попадал в отдельную проблемную ветку backend-обработки.

---

## 2. Диагностика проблемы

### 2.1. Что ломалось
- В `provider/internal/core/client.go` create-flow делал `GET /instanceOperations/{opUid}?fields=cfsParams` сразу после создания операции.
- Для VDC этот запрос приводил к ошибке backend’а:
  - `Invalid call of the function [getResourceRealmConfig]`
  - `Cannot cast Object type [Struct] to a value of type [string]`
  - источник ошибки: `/app/api/v1/resources/instance_operation_cfs_param.cfc`
- Причина по отчету: для `vc_vdc` вычислялся динамический `descr` у `storageConfig.name`, и backend падал на `resourceRealm`, который в DEV хранится как `Struct`, а не `string`.

### 2.2. Почему обычные сервисы не ломались
- На обычных сервисах этот `GET` либо не попадал в проблемный backend-код, либо не требовал вычисления `resourceRealm`.
- Для VDC в YAML есть специфическая зависимость:
  - `generated/dev/resources_yaml/21_vc_vdc.yaml`
  - `storageConfig.name` содержит вычисляемый `descr` с `getResourceRealmConfig(...resourceRealm...)`.
- Для обычных сервисов, например `vapp` и `postgres`, такого вычисляемого `resourceRealm`-контекста нет.

### 2.3. Почему `hasUnresolvedParams` мешал
- Эвристика проверяла **все** строковые параметры, а не только параметры с `ref_svc_id`.
- Для VDC это ломало fallback на обычных литералах вроде:
  - `providerVdc = fast-2.8`
  - `networkProvider = default`
- Эти значения не UUID и не JSON, но и резолвить их не нужно.
- В результате при падении GET провайдер вместо продолжения переходил в ошибку.

---

## 3. Диалог с Opus

### 3.1. Что просили у Opus
- Проверить только:
  - `provider/internal/core/client.go`
  - `docs/DEBUG_REPORT_VC_VDC_500.md`
  - `generated/dev/resources_yaml/21_vc_vdc.yaml`
  - `generated/dev/resources_yaml/26_vapp.yaml`
  - `generated/dev/resources_yaml/90_postgres.yaml`
- Вопросы к Opus были узкими:
  1. почему обычные сервисы работали, а VDC начал падать на `GET ?fields=cfsParams`
  2. есть ли в VDC специфическая структура или зависимость, которой нет у обычных сервисов
  3. является ли `hasUnresolvedParams` неверной эвристикой именно в этом месте
  4. что именно надо исправить

### 3.2. Что ответил Opus по сути
- Root cause — не данные Terraform и не сами строки `fast-2.8` / `default`, а backend-ошибка на `GET /instanceOperations/{opUid}?fields=cfsParams` именно для VDC.
- VDC отличается от обычных сервисов тем, что в его YAML есть динамический `descr` для `storageConfig.name`, который тянет `resourceRealm`.
- `hasUnresolvedParams` была признана лишней и хрупкой эвристикой: она может ломать fallback на обычных строках.
- Итоговое решение Opus: при ошибке GET идти дальше по браузерному flow, без условий по всем строковым параметрам.

### 3.3. Дополнительные уточнения в диалоге
- Был отдельный спор по формулировке про Lucee / ColdFusion backend.
- В итоге было зафиксировано, что этот термин — не отдельная гипотеза, а просто обозначение backend-слоя, который уже фигурировал в отчетах и traceback’ах.
- Opus также подтвердил, что для VDC этот GET нужен только как вспомогательный шаг для `resolveRefSvcParamValues`, а не как обязательный бизнес-этап.

---

## 4. Что изменили в коде

### 4.1. `provider/internal/core/client.go`
- В `CreateGenericInstanceUniversalV6` удалён gate по `hasUnresolvedParams`.
- Теперь логика такая:
  - если `GET /instanceOperations/{opUid}?fields=cfsParams` успешен — парсим и резолвим `ref_svc_id`
  - если GET падает — просто продолжаем POST’ить параметры, а потом идём в `validate-cfs` и `run`
- Функция `hasUnresolvedParams` удалена полностью.
- После удаления была убрана осиротевшая документационная строка, оставшаяся над `isHexDigit`.

### 4.2. `provider/internal/core/client_test.go`
- Добавлен тест:
  - `TestCreateGenericInstanceUniversalV6_ContinuesWhenOpDetailsGETFails`
- Тест моделирует:
  - `POST /instances`
  - `POST /instanceOperations`
  - `GET /instanceOperations/{opUid}?fields=cfsParams` → 500
  - `POST /instanceOperationCfsParams`
  - `GET /instanceOperations/{opUid}/validate-cfs`
  - `POST /instanceOperations/{opUid}/run`
  - финальный `GET /instances/{uid}`
- Проверка теста:
  - create-flow завершился успешно
  - все 7 параметров были отправлены с ожидаемыми значениями
  - polling по операции был ровно один раз

---

## 5. Проверка после правки
- `cd /home/naeel/TF/tf_provider/provider && go test ./internal/core` — успешно.
- После ревью был пойман и исправлен только косметический хвост:
  - старый комментарий над `isHexDigit`, оставшийся после удаления `hasUnresolvedParams`.
- После этого пакет `internal/core` снова прошёл тесты.

---

## 6. Вывод по итогам сессии
- Проблема была не в обычных сервисах как таковых, а в специфике VDC-данных и backend-пути, который срабатывал на `GET ?fields=cfsParams`.
- `hasUnresolvedParams` была неверной эвристикой именно в create-flow VDC и ломала рабочий fallback.
- Правильное поведение: если GET падает, не гадать по строковым параметрам, а продолжать browser-like flow через POST параметров, validate и run.

---

## 7. Что дальше
- Следующий этап — уже не правка логики, а публикация и стендовая проверка при необходимости.
- DEV-релиз `2.0.3` успешно собран и загружен в registry `nubes-dev` через `TOOLS/scripts/03_build_and_upload_provider.sh --profile TOOLS/config/dev`.
- Перед этим уже был подготовлен короткий запрос на ревью для Opus и получен ответ, который подтвердил направление правки.