Strukturiertes Logging (log/slog) mit Korrelations-ID ueber HTTP-Anfragen
(Middleware, X-Request-Id) und Hintergrund-Jobs (Job-ID als ID im Kontext,
jobqueue.Worker und dms-worker-Retention-Pfad) hinweg. Logger ist
Konstruktor-Pflichtfeld (internal/errortracking.New panic'ed ohne Logger),
um das im Ticket beschriebene stille Fehlen von Debug-Logs auszuschliessen.
Metriken (internal/metrics) im Prometheus-Textformat unter /metrics:
HTTP-Anfragen nach Status, Fehlerrate, durchschnittliche Dauer,
Job-Queue-Laenge (neue jobqueue.Queue.QueueLength). Kein neuer
Prometheus-Client als Abhaengigkeit, da vor dieser Kachel keine
Metrik-Bibliothek im Einsatz war.
Zentrales Fehler-Tracking (internal/errortracking): In-Prozess-Ringpuffer
+ strukturiertes Error-Log, Schwellwert-Alarm (N Fehler in Zeitfenster)
mit Acknowledge. In cmd/app per Recover-Middleware, in cmd/worker im
Retention-Register-Requeue-Pfad verdrahtet.
Basis: feature/fdn-09-verschluesselung-at-rest-schluesselverwaltung (enthaelt
FDN-04, wovon FDN-11 laut Ticket abhaengt; fdn-10 wurde NICHT als Basis
genommen, da FDN-04 kein Vorfahre von fdn-10 ist).
Ergaenzt harte, konfigurierbare Obergrenzen je Verarbeitungsjob (Zeit,
Speicher, Eingabegroesse/Seitenzahl) um internal/jobqueue: Ueberschreitung
fuehrt zum kontrollierten Abbruch in die Dead-Letter-Queue statt zur
Blockade des Workers, inkl. Nutzerbenachrichtigung ueber ein neues
Notifier-Interface.
- limits.go: Limits-Struct, DefaultLimits, Vorab-Pruefung von
size_bytes/pages aus den Job-Metadaten vor Handler-Start
- notifier.go: Notifier-Interface + LogNotifier als Standard
- queue.go: Queue.FailPermanently fuer sofortigen DLQ-Transfer (kein
Backoff/Retry bei Ressourcenlimit-Verstoss)
- worker.go: Worker.runWithLimits fuehrt Handler mit Zeit-Timeout und
Speicher-Sampling (runtime.MemStats, prozessweite Annaeherung) aus und
kehrt bei Ueberschreitung sofort zurueck statt zu blockieren
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Postgres-Jobqueue (processing_jobs, FOR UPDATE SKIP LOCKED), In-Prozess-
Worker-Goroutinen, kein Redis/AMQP. Enqueue mit Idempotency-Key-Dedup,
Dequeue mit Stale-Lock-Wiedervorlage (Absturzsicherheit), Fail mit
arithmetischem Backoff und Dead-Letter-Queue nach erschoepften Versuchen,
RequeueDeadLetter fuer manuelle Wiederholung.
Auf 192.168.1.131 verifiziert: Absturz-Wiedervorlage (Job von einem
"abgestuerzten" Worker nie completed/failed, zweiter Worker holt ihn nach
Ablauf der Sperre erneut), Idempotenz bei Doppelzustellung (gleicher
idempotency_key erzeugt nur 1 Zeile), DLQ-Eintrag manuell wiederholbar.
Vier reale Fehler beim Testen gefunden und behoben: zwei pgx-Typinferenz-
Bugs im SQL-Parameterhandling (toter workerID-Parameter ohne Referenz in
der Query; untypisiertes any statt []string fuer den ::text[]-Cast), sowie
zwei Testinfrastruktur-Bugs (dms_tenant_test sammelte schema_migrations-
Zustand ueber Sitzungen hinweg an, jobqueue-Testfixture raeumte
processing_jobs nicht auf) - neues scripts/reset-test-env.sh + make check
(-p 1) analog Core behoben.
Siehe dms/docs/FDN-04-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
patrick
