Files
sless/doc/SESSION_REPORT_2026-04-03.md
T
Repinoid 6dc2dc69ba IoT MVP: архитектура, план реализации, лог рассуждений
- Определена архитектура managed IoT service
- Согласовано решение: RabbitMQ (MVP), потом Kafka; EMQX + CRD контроллер
- Создан подробный план для Sonnet (doc/iot-mvp-plan.md)
- Добавлено правило в copilot-instructions: лог мышления в doc/thinking/ по датам
- Полный ход рассуждений в doc/thinking/2026-04-04.md

Ключевые решения:
- IoT код в iot/ (легко вынести потом)
- CRD IoTDevice + контроллер (как все остальное в sless)
- EMQX HTTP Auth Backend для динамической аутентификации устройств
- Архитектура broker-agnostic (легко переключить на Kafka)
- Terraform: расширяем текущий provider (sless_iot_device ресурс)
2026-04-04 08:34:14 +03:00

6.2 KiB

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

    • 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

    • 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

    • 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:

  • Commented out nubes_postgres_database resource block (lines 87-99)
  • Updated outputs.tf to disable database-dependent outputs
  • 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/

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