sysopsandClaude Sonnet 5
6a03dcafd6
internal/health: wiederverwendbare Registry fuer benannte Checks (DB, Queue) — nicht Core-spezifisch, sondern von jedem registrierten Modul (API-02) gleichermassen einsetzbar. LivenessHandler prueft bewusst KEINE externen Abhaengigkeiten (Akzeptanzkriterium 2: Liveness/Readiness getrennt) — ein DB-Ausfall soll den Prozess nicht faelschlich als "tot" markieren und einen grundlosen Neustart ausloesen. ReadinessHandler fuehrt alle registrierten Checks NEBENLAEUFIG mit je eigenem Timeout aus (DefaultCheckTimeout=2s) und liefert 503, sobald irgendeine Abhaengigkeit fehlschlaegt (Akzeptanz- kriterium 1 + 3) — echte Pruefung von DB (Ping) und Job-Queue statt nur Prozessstatus. Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. Simulierter Datenbankausfall fuehrt zu "nicht bereit" — TestReadinessHandler_ReportsNotReadyOnDatabaseFailure: geschlossener Pool, 503 mit "database" im Checks-Ergebnis. PASS. 2. Health-Endpunkt antwortet auch bei haengendem Check innerhalb definierter Zeit — TestReadinessHandler_RespondsWithinTimeoutEvenWithHangingCheck: ein 10s blockierender Check wird durch 50ms-Timeout begrenzt, Handler antwortet deutlich unter 1s. PASS. 3. Readiness- und Liveness-Antwort unterscheiden sich nachweislich in mindestens einem Fehlerfall — TestLivenessAndReadiness_DifferOnDatabaseFailure: bei DB-Ausfall liefert Liveness weiterhin 200, Readiness 503. PASS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
13 lines
432 B
Bash
Executable File
13 lines
432 B
Bash
Executable File
#!/usr/bin/env bash
|
|
set -euo pipefail
|
|
PASS="${NEXARCH_TEST_DB_PASSWORD:?Setze NEXARCH_TEST_DB_PASSWORD vor dem Aufruf}"
|
|
cd "$(dirname "$0")/.."
|
|
NEXARCH_TEST_DB_PASSWORD="$PASS" bash scripts/reset-test-env.sh
|
|
export TEST_ADMIN_DSN="postgresql://nexarch_test:${PASS}@localhost:5432/postgres?sslmode=disable"
|
|
echo "== go build =="
|
|
go build ./...
|
|
echo "== go vet =="
|
|
go vet ./...
|
|
echo "== go test (-p 1) =="
|
|
go test ./... -p 1 -count=1
|