mirror of
https://github.com/taylanbakircioglu/haproxy-openmanager.git
synced 2026-09-22 18:43:26 +00:00
d6ee9517d0
CRITICAL FIX: has_pending_config calculation for both backends and frontends
Problem Found (Console Log):
Backend/Frontend: {
last_config_status: 'APPLIED', <- Already applied!
has_pending_config: true, <- But flag is TRUE!
is_active: false <- Inactive (soft-deleted)
}
Apply response: 'No pending changes to apply'
Reject response: 'No pending changes found to reject'
Result: Entity stuck in Apply Management forever!
Root Cause:
OLD LOGIC (backend.py line 438, frontend.py line 363):
has_pending_config = (config_version OR status=PENDING OR is_inactive) AND NOT rejected
For inactive + APPLIED entity:
- has_config_version: FALSE
- has_pending_status: FALSE (status=APPLIED)
- is_inactive: TRUE
- Result: TRUE (incorrectly marked as pending!)
Why It Matters:
- Design: Inactive entities should show as pending for soft-delete workflow
- Problem: Entity with is_active=FALSE + last_config_status='APPLIED' = soft-delete already applied!
- Apply/Reject: Both look for PENDING status, find none, do nothing
- UI: Entity remains in Apply Management (has_pending_config=true forever)
Solution (Both backend.py and frontend.py):
Inactive entity is only pending if last_config_status is PENDING, not APPLIED:
OLD: is_inactive → always pending
NEW: (is_inactive AND status=PENDING) → only pending if not yet applied
Formula:
has_pending_config = (
config_version OR
status=PENDING OR
(is_inactive AND status=PENDING)
) AND NOT rejected AND NOT (is_inactive AND is_applied)
Test Cases:
✅ Active entity, PENDING → pending=TRUE
✅ Active entity, APPLIED → pending=FALSE
✅ Inactive entity, PENDING → pending=TRUE (soft-delete needs apply)
✅ Inactive entity, APPLIED → pending=FALSE (soft-delete already applied) <- FIXED!
✅ Inactive entity, REJECTED → pending=FALSE
Backend.py Changes (lines 426-445):
- Added is_applied flag
- Added is_inactive_and_pending logic
- Updated has_pending_config formula
- Comprehensive comments
Frontend.py Changes (lines 359-370):
- Same logic as backend for consistency
- Inline expression (no loop variables)
- Comprehensive comments
Impact:
- 'deneme-sil' backend will show has_pending_config=FALSE
- Backend/Frontend will disappear from Apply Management
- No more stuck entities after soft-delete apply
- Agent sync race condition protected (inactive+APPLIED=not pending)
- Consistent behavior across all entity types
Related: c120445 (apply endpoint fix), f80c026 (debug logs)
Refs: #has-pending-config #inactive-entity #apply-management #consistency