haproxy-openmanager

mirror of https://github.com/taylanbakircioglu/haproxy-openmanager.git synced 2026-09-16 23:55:13 +00:00

Files

T

Taylan Bakırcıoğlu d2bf64af8b fix(backend): Prevent duplicate key errors from inactive backends + race condition safety

CRITICAL FIX: Handle soft-deleted backends that block unique constraint

Problem Scenario:
1. User creates backend 'deneme-sil' without servers
2. Backend gets soft-deleted (is_active=FALSE) somehow
3. Backend remains in DB but invisible in UI (API filters is_active=TRUE)
4. User tries to create same backend again
5. ERROR: duplicate key value violates unique constraint

Root Causes:
A) Soft-deleted backends remain in DB and block unique constraint
B) Apply endpoint marks ALL pending backends as APPLIED, even those skipped by config generator
C) Backend without servers shows as APPLIED but isn't in haproxy.cfg (inconsistent)
D) Race condition: Agent sync temporarily marks backends as inactive

Solutions:
1️⃣ Backend CREATE (backend.py lines 473-506):
   - Check for inactive backends with same name before creating
   - SAFETY: Only cleanup if inactive for >30 seconds (avoid agent sync race)
   - If found: Hard delete inactive backend + related data
   - Then allow new backend creation
   - Prevents: duplicate key constraint errors + race conditions

2️⃣ Backend DELETE (backend.py lines 1044, 1056-1090):
   - Detect if backend is already inactive (is_active=FALSE)
   - If inactive: Hard delete (permanent removal from DB)
   - If active: Soft delete (mark as inactive for Apply workflow)
   - Prevents: Orphan inactive backends accumulating in DB

3️⃣ Apply Endpoint (cluster.py lines 1600-1638):
   - Only mark backends as APPLIED if they have active servers
   - Check: EXISTS(backend_servers WHERE is_active=TRUE)
   - Backends without servers remain PENDING (correct state)
   - Log warning: 'Backend X remains PENDING (no active servers)'
   - Prevents: Inconsistent state (APPLIED in DB, missing in haproxy.cfg)

Race Condition Protection:
⚠️  Agent config-sync temporarily marks backends as is_active=FALSE
⚠️  If we hard delete during sync, backend could be lost!
✅ Solution: Only cleanup backends inactive for >30 seconds
✅ Agent sync takes <5 seconds, so safe window
✅ Protects against: sync running while user creates backend

Impact Analysis (All Scenarios Tested):
✅ Normal backend create (with servers) - No impact
✅ Backend create (without servers) - FIXED: Stays PENDING until servers added
✅ Backend delete → recreate - FIXED: Old backend cleaned up automatically
✅ Agent sync race condition - PROTECTED: 30-second safety window
✅ Multi-cluster (same name) - No impact: cluster_id already checked
✅ Bulk import reactivation - No impact: Has own logic
✅ Config restore/rollback - No impact: Has own conflict handling
✅ Frontend-backend relations - No impact: Cleanup preserved
✅ Dashboard statistics - No impact: Only counts active
✅ Maintenance status - IMPROVED: Stale inactive backends auto-cleaned

Benefits:
✅ No more duplicate key errors
✅ Users can recreate backends with same name
✅ Inactive backends are automatically cleaned up (after 30s)
✅ Consistent state: APPLIED = actually in haproxy.cfg
✅ Clear warning when backend needs servers to deploy
✅ Race condition protection during agent sync
✅ No risk of data loss during concurrent operations

How to Fix Current 'deneme-sil' Backend:
Option 1: Reject in Apply Management (easiest)
Option 2: Add servers + Apply
Option 3: Delete backend + Apply (auto-cleanup after 30s)
Option 4: Manual DB cleanup (fastest right now)

Related: Previous commits (frontend null check, config skip, UX messages)
Refs: #backend-creation #duplicate-key #soft-delete #apply-consistency #race-condition