tf_provider/docs/40_analysis/postgres_backend_bugs_2026-02-28.md

PostgreSQL backend bugs (2026-02-28)

Scope

Environment: TEST API (deck-api-test.ngcloud.ru), instance UID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Source evidence: UI/F12 HAR (pguser.har) and Terraform provider runs.

Bug 1: delete_user returns not found, but user is still present

Observed behavior

• UI sends delete_user correctly:
  • POST /instanceOperations with operation=delete_user
  • POST /instanceOperationCfsParams with svcOperationCfsParamId=739 and paramValue=<username>
  • POST /instanceOperations/<opUid>/run
• Operation completes with backend error (example):
  • Пользователь postuser не найден в кластере
• After operation, instances/<uid>?fields=state still reports both users in state.out.users.

Impact

• Deletion result is inconsistent with visible instance state.
• Terraform can only soft-handle this as warning, but cannot guarantee real deletion.

Example operation UIDs from HAR

• xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (delete postuser)
• xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (delete postusernew)

Bug 2: recovery fails with HTTP 500 (missing FILECONTENT)

Observed behavior

• Terraform call to nubes_postgres_recovery creates and runs operation, but backend returns 500.
• API error payload:
  • ERROR: key [FILECONTENT] doesn't exist
  • stack in /app/api/v1/resources/instance_operation_run.cfc line 281
  • message indicates operation path expects create-context metadata (contragentCode/authHeader).

Impact

• recovery is not runnable via provider/API for this instance path.
• Action currently works only from client frontend context (if that path injects required job metadata).

Expected backend behavior

• delete_user should be deterministic:
  • if user exists -> delete and reflect removal in state.out.users;
  • if user absent -> return explicit idempotent result, not stale state.
• recovery should not depend on missing frontend-only fields when called via public API flow.

Requested backend fixes

1. Fix source of stale/mismatched user existence for delete_user.
2. Make instance_operation_run resilient when job.filecontent is missing.
3. Align recovery execution path for API/provider calls without requiring frontend-only auth context.

Control check: restart works

For the same instance and environment, nubes_postgres_restart was executed from Terraform and completed successfully.

This confirms the provider transport/auth path is valid in general, and the observed failures are specific to delete_user/recovery backend execution paths.

Additional evidence: recovery fails from UI too

recovery failure is reproducible not only from Terraform/API, but also from the personal cabinet (frontend).

Reference operation:

• instanceOperationUid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
• operation: recovery
• instanceUid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
• submitResult: 201
• isSuccessful: false
• duration: 59.2s
• errorLog: Не удалось услугу k8s-Pgsql | SYSTEM | Для операции create не переданы contragentCode/authHeader. Убедитесь, что инстанс запущен из клиентского фронтэнда

Conclusion: this is a backend execution-path defect for recovery (service side), independent of Terraform client behavior.