add: documentation

2026-06-30 15:45:24 +04:00
parent 540c1f7293
commit ca276d200f
1055 changed files with 47294 additions and 0 deletions
@@ -0,0 +1,79 @@
+# 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.