Files
taylanbakircioglu a87994e06a fix(vip): refuse adoption that strands a node or normalises a peer (v1.10.9)
Three findings from a second pass over the adoption flow, all of the same
class: something real leaving the set silently.

1. STRANDING. _collect_instance_participants can only match a node it can
   READ, that is ENABLED, and that is in the SAME pool. Each of those is a door
   a genuine member of the VRRP group leaves through without a word, and the
   nodes that remain are rewritten while it keeps serving the same address from
   an unmanaged config. Found on a live pool: one node of a pair had an
   unclosed vrrp_instance block, so it parsed to nothing while its partner
   parsed cleanly.

   Rather than guard each door, ask the question directly: does any reported
   keepalived.conf mention THIS virtual address without being one of the nodes
   we are about to adopt? Refuses naming the node and the reason. Scoped on the
   address so an unrelated file elsewhere cannot block every adoption, and
   excluding nodes already under management (a standing VIP, or our ownership
   marker) because those are not stranded.

2. SILENT NORMALISATION. prefix_length, unicast/multicast mode, HAProxy
   tracking and the VRRP password are stored ONCE on the VIP and re-rendered
   onto EVERY member, so whichever node was clicked imposed its settings on the
   others. prefix_length is the sharpest: the design refuses to GUESS a netmask
   for a live VIP, and copying one node's netmask onto another is that same
   change wearing a different hat. All four must now agree, with both values
   named in the refusal. The VRRP secret is compared by decrypting each node's
   token - Fernet is non-deterministic, so ciphertexts cannot be compared - and
   a token that will not decrypt is an error rather than an assumed match.

3. THE TAKEOVER AUTHORISATION WAS NOT ONE-SHOT. takeover_expected_hash is the
   permission to overwrite a keepalived.conf that lacks our ownership marker.
   It was written at adoption and never cleared, so it stayed valid for that
   file content indefinitely: restoring the pre-adoption file would have been
   overwritten again with no fresh human approval. It is now retired when a
   member acknowledges our rendered config, gated on the acked hash matching
   applied_config_hash so a partial or failed deploy never drops it and leaves
   the VIP unable to converge.

The panel applies the stranding rule too, so the Adopt button is disabled with
the reason instead of letting the operator click into a 422.

No schema change, no agent change, no API-shape break.

Backend suite: 1366 passed, 152 skipped. Frontend build clean.
2026-08-14 07:55:07 +03:00
..
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00

HAProxy Management UI - Unit Tests

Overview

Comprehensive unit test suite for the HAProxy Management UI backend, covering critical business logic and ensuring reliability.

Test Structure

Backend Tests (backend/tests/)

  • test_soft_delete.py - Soft delete functionality and unique constraints
  • test_apply_process.py - Critical apply process that manages entity states
  • test_entity_sync.py - Entity-specific agent sync calculations
  • test_haproxy_config.py - HAProxy configuration generation
  • test_auth.py - Authentication and authorization

Frontend Tests (frontend/src/components/__tests__/)

  • EntitySyncStatus.test.js - Agent sync status component
  • ApplyManagement.test.js - Apply management workflow
  • SSLManagement.test.js - SSL certificate management

Running Tests

Backend Tests

# Install test dependencies
pip install -r backend/requirements-test.txt

# Run all tests
pytest

# Run specific test file
pytest backend/tests/test_apply_process.py

# Run with coverage
pytest --cov=backend --cov-report=html

# Run specific test
pytest backend/tests/test_soft_delete.py::TestSoftDeleteUniqueConstraints::test_backend_soft_delete_allows_name_reuse

Frontend Tests

# Run all frontend tests
npm test

# Run with coverage
npm run test:coverage

# Run in CI mode
npm run test:ci

Test Coverage Goals

  • Backend: 70% minimum coverage
  • Frontend: 70% minimum coverage
  • Critical paths: 90%+ coverage (apply process, soft delete, entity sync)

Critical Test Areas

🔴 HIGH PRIORITY

  1. Apply Process - Prevents entity disappearance bugs
  2. Soft Delete Logic - Ensures proper unique constraint handling
  3. Entity Sync Calculations - Agent sync status accuracy
  4. Authentication/Authorization - Security validation

🟡 MEDIUM PRIORITY

  1. HAProxy Config Generation - Configuration correctness
  2. SSL Management - Certificate lifecycle
  3. Form Validations - Input validation

🟢 LOW PRIORITY

  1. UI Components - Visual behavior
  2. Utility Functions - Helper functions

Mock Strategy

Backend Mocking

  • Database connections: AsyncMock for database operations
  • External APIs: Mock HTTP calls
  • File operations: Mock file system access

Frontend Mocking

  • API calls: Mock axios requests
  • Ant Design components: Mock component behavior
  • Context providers: Mock React contexts

Test Data

All tests use consistent mock data from conftest.py:

  • Sample clusters, backends, frontends
  • Mock users and authentication
  • Config versions and SSL certificates

Debugging Tests

# Run with verbose output
pytest -v -s

# Run specific failing test
pytest backend/tests/test_apply_process.py::TestApplyProcess::test_apply_process_preserves_active_entities -v -s

# Drop into debugger on failure
pytest --pdb

Integration with CI/CD

Tests are designed to run in Azure DevOps pipeline:

# Example pipeline step
- script: |
    pip install -r backend/requirements-test.txt
    pytest --cov=backend --cov-report=xml
  displayName: 'Run Backend Tests'

- script: |
    npm ci
    npm run test:ci
  displayName: 'Run Frontend Tests'

Adding New Tests

  1. Follow naming convention: test_*.py for backend, *.test.js for frontend
  2. Use appropriate fixtures: Leverage existing mock data
  3. Test edge cases: Include error scenarios and boundary conditions
  4. Update coverage: Ensure new code maintains coverage thresholds

Common Issues

Backend

  • Async tests: Use @pytest.mark.asyncio decorator
  • Database mocking: Ensure proper mock setup for database operations
  • Import paths: Use relative imports for testable modules

Frontend

  • Component rendering: Wait for async operations with waitFor
  • Event simulation: Use fireEvent for user interactions
  • Mock cleanup: Clear mocks between tests with jest.clearAllMocks()

Test Philosophy

These tests focus on:

  • Business logic correctness over implementation details
  • Critical path coverage over 100% coverage
  • Regression prevention based on actual bugs encountered
  • Maintainability with clear, readable test cases

The test suite is designed to catch the types of bugs we've actually encountered in production, particularly around the apply process and soft delete behavior.


Test deployment trigger - $(date)