Fix VDC flow and FullPipe example

2026-09-21 13:02:25 +03:00
parent 7d446977a5
commit 1ec6a0fedc
8 changed files with 196 additions and 59 deletions
@@ -0,0 +1,111 @@
+# Резюме сессии: 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 и получен ответ, который подтвердил направление правки.