tf_provider/docs/CHAT_RESUME_2026-09-21.md

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