Files
taylanbakircioglu d7208528f7 fix: v1.5.2 — ACME Diagnostics Panel Hardening + AGPL-3.0 relicense (Bulgu #94/#95/#96)
A focused hardening pass on the v1.5.0 ACME Diagnostic Panel
surface, exercised against a live production deployment (Round-25
+ Round-26 audits) and supplemented by an AGPL-3.0 relicense.

------------------------------------------------------------------
LICENSE — Relicense to AGPL-3.0-or-later
------------------------------------------------------------------
Effective v1.5.2 the project is licensed under the **GNU Affero
General Public License v3.0 (or later)**. v1.5.0 and v1.5.1
remain under the prior MIT terms.

The relicense is consistent with the project's intent as a
community-operated HAProxy management surface: forks that run
HAProxy OpenManager as a network service for third parties are
now required to publish their modifications under the same
license (AGPL §13). Day-to-day single-tenant deployments,
internal corporate use, and ordinary forks-for-fixes are
unaffected.

Changes:
  * LICENSE replaced with full AGPL-3.0 text.
  * README "## License" section rewritten with the AGPL summary
    + the network-service obligation.
  * frontend/package.json gains `"license": "AGPL-3.0-or-later"`.

------------------------------------------------------------------
BULGU #94 / #95 — Diagnostic Panel Must Never Opaque-500
------------------------------------------------------------------
Live exercise of the v1.5.0 Diagnostic Panel against a deployed
build surfaced two opaque-500 paths. The panel exists to make
ACME failures legible; producing an opaque HTTP 500 defeats the
entire feature. Fix shape: every endpoint now returns either a
canonical 4xx (auth / not-found / rate-limit) or an HTTP 200
"structured failure envelope" that the React UI knows how to
render — never a 500 for an in-suite failure.

Affected paths:

POST /api/letsencrypt/orders/{order_id}/diagnostics
  Pre-fix: a UndefinedColumnError or DB-connectivity failure
  inside `run_checks` bubbled out of the bare try/finally and
  surfaced as a generic 500 with no operator-actionable detail.
  Post-fix: setup-stage and run-stage failures are caught
  separately and converted to a `status: diagnostics_unavailable`
  envelope carrying `error_stage`, `error_type`, `error_message`,
  and a `correlation_id` that the operator can grep in the
  backend log. Individual checks are wrapped in `_safe_check`
  so one broken check (e.g. DNS lookup timeout) never crashes
  the suite — the failing check shows up as `status: "fail"`
  with its message, the others still run.

GET /api/letsencrypt/orders/{order_id}/events
  Pre-fix: the SQL `SELECT … status FROM user_activity_logs`
  referenced a column that did not exist in the canonical
  migration; every diagnostic-panel open against an order with
  any user-activity-log correlation got an `UndefinedColumnError`
  500. Post-fix: the endpoint now introspects
  `information_schema.columns` and projects only the columns
  actually present. Partial failures (one source dies, the
  other works) are reported via `meta.errors[]` rather than
  collapsing the whole timeline.

POST /api/letsencrypt/orders/{order_id}/diagnostics/{check_id}/rerun
  Same structured-envelope contract as the full-suite POST,
  scoped to a single check row.

Frontend (`frontend/src/components/ACMEAutomation.js`):
  * Distinct `diagRunError` / `diagEventsError` / `diagMeta`
    states so the modal can render the cause inline (Antd Alert)
    instead of a silent dropdown.
  * Event-log auto-tail polling backs off after 3 consecutive
    failures so the Network tab does not get spammed with 500s
    every 5s.
  * Correlation IDs visible in every error banner.

------------------------------------------------------------------
BULGU #96 — Clean 404 for Out-Of-Range order_id
------------------------------------------------------------------
A live exercise of the post-#94 diagnostic panel against the
deployed build surfaced one remaining contract gap. A path-
param `order_id` outside the Postgres int4 range
(e.g. > 2_147_483_647) caused `_load_order` to raise
`asyncpg.exceptions.DataError: invalid input for query
argument $1: 2147483648 (value out of int32 range)`. Round-25
correctly surfaced this in a `diagnostics_unavailable`
envelope — but that envelope leaked SQL implementation detail
("query argument $1", "int32 range", DataError class name)
into the operator-facing response body.

Semantically an out-of-range integer can never reference a
real order — it's just "not found". `_load_order` now catches
`asyncpg.exceptions.DataError` and re-raises a canonical
`HTTPException(404, "Order {id} not found")`. Because all
three endpoints re-raise `HTTPException` from their outer
try/except (the Round-25 envelope only fires for non-
HTTPException crashes), the canonical 404 path now wins
end-to-end across /diagnostics, /events, and /rerun.

------------------------------------------------------------------
TEST / LINT / LIVE VERIFICATION
------------------------------------------------------------------
  * Backend pytest 1104/1104 (the +20 vs v1.5.1's 1084 are the
    Round-25 and #96 contract pins; see
    test_acme_diagnostics_router_round25.py).
  * Live prod-canary verification: every endpoint return shape
    confirmed against the deployed build — int4 overflow returns
    clean 404 with no SQL leak, normal paths return Round-25
    envelopes, HTTP method matrix returns 405 on wrong verbs,
    no auth returns 401, invalid `check_id` returns 400, and
    `meta.correlation_id` is present on every diagnostic
    response.

------------------------------------------------------------------
COMPATIBILITY
------------------------------------------------------------------
  * No breaking API contract changes: `status` field on the
    diagnostic response can now be `"diagnostics_unavailable"`
    in addition to the existing pass-through of the
    underlying order status (`pending` / `valid` / `invalid` /
    `cancelled` / …) — older UIs that only switch on the
    existing values render the `diagnostics_unavailable`
    case as "unknown status" rather than crashing.
  * Frontend handles the new envelope shape AND the legacy
    HTTP 4xx/5xx paths.
2026-05-14 00:07:00 +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)