Lukas
52f237d5d4
CRITICAL FIX: Background tasks (especially blocklist_import) crashed mid-execution, leaving partial state. On retry, the same bans were applied again, causing duplicates. Solution: Content-hash based operation tracking for blocklist imports: - Added import_runs table (migration 6) to track operations by source + content hash - Before banning, check if this exact content has already been imported - If completed: skip banning (already done), optionally re-warm cache - If new or failed: proceed with ban and mark as completed or failed Changes: - Database: Migration 6 adds import_runs table with operation state tracking - Model: Added ImportRunEntry for import run records - Repository: New import_run_repo module with CRUD operations - Workflow: Updated blocklist_import_workflow to check operation history before banning - Dependencies: Registered import_run_repo for dependency injection - Tests: Added test_import_source_idempotent_on_retry and test_import_source_different_content_not_reused - Documentation: Added Task Idempotency section to Backend-Development.md Verification: - All 7 import tests pass (5 existing + 2 new idempotency tests) - Type checking: mypy --strict ✅ - Linting: ruff ✅ - No API changes, backwards compatible via automatic migration Fixes: Background tasks not idempotent #CRITICAL Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
114 lines
3.6 KiB
Python
114 lines
3.6 KiB
Python
"""Health-check background task.
|
|
|
|
Registers an APScheduler job that probes the fail2ban socket every 30 seconds
|
|
and stores the result on ``app.state.server_status``. The dashboard endpoint
|
|
reads from this cache, keeping HTTP responses fast and the daemon connection
|
|
decoupled from user-facing requests.
|
|
|
|
Crash detection (Task 3)
|
|
------------------------
|
|
When a jail activation is performed, the router stores a timestamp on
|
|
``app.state.last_activation`` (a ``dict`` with ``jail_name`` and ``at``
|
|
keys). If the health probe subsequently detects an online→offline transition
|
|
within 60 seconds of that activation, a
|
|
:class:`~app.models.config.PendingRecovery` record is written to
|
|
``app.state.pending_recovery`` so the UI can offer a one-click rollback.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
import datetime
|
|
from typing import TYPE_CHECKING
|
|
|
|
import structlog
|
|
|
|
from app.models.server import ServerStatus
|
|
from app.services import health_service
|
|
from app.tasks.timeout_utils import run_with_timeout
|
|
from app.utils.runtime_state import (
|
|
RuntimeState,
|
|
get_effective_settings,
|
|
get_runtime_state,
|
|
process_health_probe_result,
|
|
)
|
|
|
|
if TYPE_CHECKING: # pragma: no cover
|
|
from fastapi import FastAPI
|
|
|
|
from app.config import Settings
|
|
|
|
log: structlog.stdlib.BoundLogger = structlog.get_logger()
|
|
|
|
|
|
#: How often the probe fires (seconds).
|
|
HEALTH_CHECK_INTERVAL: int = 30
|
|
|
|
#: Maximum seconds to allow for health probe to complete.
|
|
HEALTH_PROBE_TIMEOUT_SECONDS: int = 10
|
|
|
|
|
|
async def _run_probe_with_resources(settings: Settings, runtime_state: RuntimeState) -> None:
|
|
"""Probe fail2ban and cache the result on the runtime state.
|
|
|
|
Args:
|
|
settings: The resolved application settings used for the probe.
|
|
runtime_state: The mutable runtime state manager.
|
|
"""
|
|
|
|
async def _do_probe() -> None:
|
|
socket_path: str = settings.fail2ban_socket
|
|
status: ServerStatus = await health_service.probe(socket_path)
|
|
process_health_probe_result(runtime_state, status)
|
|
|
|
await run_with_timeout("health_check", _do_probe(), HEALTH_PROBE_TIMEOUT_SECONDS)
|
|
|
|
|
|
async def _run_probe(app: FastAPI) -> None:
|
|
await _run_probe_with_resources(
|
|
get_effective_settings(app),
|
|
get_runtime_state(app),
|
|
)
|
|
|
|
|
|
async def run_probe(app: FastAPI) -> None:
|
|
"""Run a single health probe outside the scheduled job context."""
|
|
await _run_probe(app)
|
|
|
|
|
|
def register(app: FastAPI) -> None:
|
|
"""Add the health-check job to the application scheduler.
|
|
|
|
Must be called after the scheduler has been started (i.e., inside the
|
|
lifespan handler, after ``scheduler.start()``).
|
|
|
|
Args:
|
|
app: The :class:`fastapi.FastAPI` application instance whose
|
|
``app.state.scheduler`` will receive the job.
|
|
"""
|
|
# Initialise the cache with an offline placeholder so the dashboard
|
|
# endpoint is always able to return a valid response even before the
|
|
# first probe fires.
|
|
settings = get_effective_settings(app)
|
|
runtime_state = get_runtime_state(app)
|
|
|
|
runtime_state.server_status = ServerStatus(online=False)
|
|
|
|
# Initialise activation tracking state.
|
|
runtime_state.last_activation = None
|
|
runtime_state.pending_recovery = None
|
|
|
|
app.state.scheduler.add_job(
|
|
_run_probe_with_resources,
|
|
trigger="interval",
|
|
seconds=HEALTH_CHECK_INTERVAL,
|
|
kwargs={"settings": settings, "runtime_state": runtime_state},
|
|
id="health_check",
|
|
replace_existing=True,
|
|
# Fire immediately on startup too, so the UI isn't dark for 30 s.
|
|
next_run_time=datetime.datetime.now(tz=datetime.UTC),
|
|
)
|
|
log.info(
|
|
"health_check_scheduled",
|
|
interval_seconds=HEALTH_CHECK_INTERVAL,
|
|
)
|