# Session Report: PostgreSQL Discovery - April 3, 2026

## Session Overview

**Duration**: Single session, April 3, 2026  
**Focus**: Root cause analysis of PostgreSQL terraform lifecycle tests failures  
**Outcome**: 2 major problems identified and documented

---

## Key Findings

### 1. ERR-PG-02: FIXED ✅

**Previously**: ID going to `(known after apply)` during Update operations

**Status**: Already fixed in current provider code (`internal/provider/postgres_resource.go` line ~845)
- Code now explicitly preserves ID from state during Update
- No longer reproducible - no destroy+recreate of dependent resources

**Verification**: `terraform plan` shows `0 to destroy` (correct behavior)

---

### 2. ERR-PG-06: RECLASSIFIED 🔄

**Previously**: Claimed that only 1 user per PostgreSQL instance could be created with vault_secrets

**Corrected Finding**: Multiple users work fine when properly configured
- Successfully created `pg_test_user` (user0) and `pg_test_user3` (u3)
- Both have vault_secrets successfully populated

**Root Cause of Original Error**: Lack of `depends_on` between user resources → race condition in Vault writes

**Solution**: Strict `depends_on` chain between users is required and works perfectly

---

### 3. ERR-PG-08: NEW PROBLEM ❌

**Description**: After Update operation completes (even successfully), creating dependent resources fails with 422 "Concurrent operations are not supported"

**Symptoms**:
```
Error: Ошибка клиента
  ошибка API 422: {
    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
  }
```

**Root Cause**: Nubes API maintains internal lock on instance even after operation completion. Post-operation async tasks (Vault sync, state reconciliation) still run.

**Impact**: Cannot create databases or additional users immediately after instance update in same Terraform apply

**Workaround Found**: Split apply into phases (comment out DB resource, apply, uncomment, apply again)

**Requires**: Provider fix - add post-completion delay or retry mechanism in `WaitForOperation()` method

---

## Documentation Created

1. **[/home/naeel/remote_dev/sless/doc/ERR-PG-08-concurrent-operations.md](./ERR-PG-08-concurrent-operations.md)**
   - Detailed problem analysis
   - 3 solution options (fixed delay, retry mechanism, instance state query)
   - Recommendation: combine options 1 + 2

2. **Updated [/home/naeel/remote_dev/sless/doc/errors/log.md](./errors/log.md)**
   - Added corrections to ERR-PG-06 (multi-user now works)
   - Added new section for ERR-PG-08 (concurrent ops limitation)

3. **Updated [/home/naeel/remote_dev/sless/doc/pg-terraform-behavior.md](./pg-terraform-behavior.md)**
   - Table (section 6) updated: shows 2nd/3rd user creation now works
   - Added section 3.5: detailed ERR-PG-08 explanation
   - Corrected: "2 users per instance" now says "Works with depends_on"

---

## Terraform Configuration Status

**Current Setup** (`examples/PG_TEST`):
- ✅ `nubes_postgres` instance created successfully
- ✅ `pg_test_user` (user0) created successfully  
- ✅ `pg_test_user3` (u3) created successfully
- ❌ `pg_test_db` cannot be created (blocked by ERR-PG-08)

**Workaround Applied**:
- [x] Commented out `nubes_postgres_database` resource block (lines 87-99)
- [x] Updated outputs.tf to disable database-dependent outputs
- [x] Successfully applied (0 added, 1 changed, 0 destroyed)

**Status**: Awaiting provider fix to re-enable database creation

---

## Provider Source Files

**Identified locations** for fix:
- `/home/naeel/terra/terraform/internal/provider/client_impl.go` line 240
  - `WaitForOperation()` method needs post-completion handling
  - Current: returns immediately on `IsSuccessful = true`
  - Needed: add delay or retry mechanism

- `/home/naeel/terra/terraform/internal/provider/postgres_resource.go` line 617+
  - Update() method (already has ERR-PG-02 fix)
  - Would benefit from handling ERR-PG-08 retries

---

## Next Steps (For Future Sessions)

1. **Priority FIX**: Implement post-completion delay in `WaitForOperation()`
   - Add 30-60 second sleep after success return
   - Or implement exponential backoff retry for 422 errors

2. **Testing**: After fix applied
   - Re-enable `nubes_postgres_database` in postgres.tf
   - Verify `terraform apply` succeeds fully (0 destroyed)
   - Run stress tests with multiple users and databases

3. **Documentation**: After fix verified
   - Update `pg-terraform-behavior.md` table (remove ERR-PG-08 workaround)
   - Mark ERR-PG-08 as "FIXED"
   - Update provider-fix-plan.md with implementation details

4. **Codebase**: Commit changes
   - Provider fix in `/home/naeel/terra/terraform/`
   - Documentation updates in `/home/naeel/remote_dev/sless/`

---

## Files Modified This Session

### In `/home/naeel/remote_dev/sless/`

- ✅ [doc/ERR-PG-08-concurrent-operations.md](./doc/ERR-PG-08-concurrent-operations.md) — CREATED (new)
- ✅ [doc/errors/log.md](./doc/errors/log.md) — UPDATED (added corrections + ERR-PG-08)
- ✅ [doc/pg-terraform-behavior.md](./doc/pg-terraform-behavior.md) — UPDATED (table + section 3.5)
- ⚠️ [examples/PG_TEST/postgres.tf](./examples/PG_TEST/postgres.tf) — MODIFIED (commented out DB)
- ⚠️ [examples/PG_TEST/outputs.tf](./examples/PG_TEST/outputs.tf) — MODIFIED (disabled DB outputs)

### On VM `/home/naeel/terra/`

- No code changes (only investigation)
- Terraform state reflects multi-user success
- Provider source examined but not modified

---

## Lessons Learned

1. **Multi-user creation works** when using proper `depends_on` chains
2. **Vault limitation hypothesis was wrong** - it was a race condition issue
3. **Concurrent operations limit is real** and requires provider-level fix
4. **Provider already has one fix** (ERR-PG-02 id preservation) - shows active maintenance
5. **Test environment is functional** despite appearing to fail initially

---

## Technical Debt

- [ ] ERR-PG-08 requires provider fix (not blocking test framework, blocking full automation)
- [ ] Consider: Is concurrent operations lock intentional safety feature? Document if so.
- [ ] Consider: Add configurable retry delays for production resilience

---

**Session Status**: COMPLETE - Major findings documented, actionable recommendations provided

**Ready For**: Next programmer to implement provider fix based on documented analysis