<!-- ⛔ LEGACY: deck-api.ngcloud.ru ЗАКРЫВАЕТСЯ. Актуальный API: lk-api-gateway.ngcloud.ru/api/v1/svc -->
# 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.