112 lines
8.1 KiB
Markdown
112 lines
8.1 KiB
Markdown
# Резюме сессии: 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 и получен ответ, который подтвердил направление правки.
|