[Improvement] Kein Logging, keine Health-Endpunkte, keine CancellationToken #56

New issue

Open

opened 2026-09-09 20:17:04 +00:00 by Aceless · 1 comment

Aceless commented

2026-09-09 20:17:04 +00:00

Owner

Logging

Im gesamten Backend wird kein ILogger verwendet. Fehlgeschlagene Logins, Rechtefehler, Datenbankfehler und Upload-Probleme hinterlassen keine Spur. Bei einem 500 gibt es ausserhalb der Konsolenausgabe des Frameworks nichts zum Nachsehen.

Vorschlag: strukturiertes Logging (Serilog o. ae.), Correlation-Id je Request, Warn-Log bei jedem abgelehnten Zugriff, Error-Log mit Kontext in der zentralen Fehlerbehandlung.

Health

Es gibt keinen /health-Endpunkt. Docker und der Reverse Proxy koennen nicht feststellen, ob die Anwendung und ihre Datenbankverbindung funktionieren.

Vorschlag: AddHealthChecks().AddNpgSql(connectionString) und MapHealthChecks("/health"), dazu ein HEALTHCHECK im Dockerfile.

CancellationToken

Keine Controller-Action und keine Repository-Methode nimmt einen CancellationToken entgegen. Bricht der Client ab, laufen Datenbankabfragen weiter.

Vorschlag: CancellationToken durchreichen und in CommandDefinition an Dapper uebergeben.

## Logging Im gesamten Backend wird kein `ILogger` verwendet. Fehlgeschlagene Logins, Rechtefehler, Datenbankfehler und Upload-Probleme hinterlassen keine Spur. Bei einem 500 gibt es ausserhalb der Konsolenausgabe des Frameworks nichts zum Nachsehen. **Vorschlag:** strukturiertes Logging (Serilog o. ae.), Correlation-Id je Request, Warn-Log bei jedem abgelehnten Zugriff, Error-Log mit Kontext in der zentralen Fehlerbehandlung. ## Health Es gibt keinen `/health`-Endpunkt. Docker und der Reverse Proxy koennen nicht feststellen, ob die Anwendung und ihre Datenbankverbindung funktionieren. **Vorschlag:** `AddHealthChecks().AddNpgSql(connectionString)` und `MapHealthChecks("/health")`, dazu ein `HEALTHCHECK` im Dockerfile. ## CancellationToken Keine Controller-Action und keine Repository-Methode nimmt einen `CancellationToken` entgegen. Bricht der Client ab, laufen Datenbankabfragen weiter. **Vorschlag:** `CancellationToken` durchreichen und in `CommandDefinition` an Dapper uebergeben.

Aceless added the

enhancement

label

2026-09-09 20:17:04 +00:00

Aceless referenced this issue from a commit

2026-09-09 21:18:12 +00:00

Infrastruktur fuer Transaktionen, Rechtepruefung und Bild-Uploads

Aceless referenced this issue from a commit

2026-09-09 21:18:12 +00:00

Anwendungsstart: Routing, Autorisierung, Rate Limiting, Secrets

Aceless commented

2026-09-09 21:18:53 +00:00

Author

Owner

Teilweise erledigt.

Logging: ILogger wird jetzt verwendet. Der zentrale Fehler-Handler loggt jeden 500er mit Stacktrace, Methode und Pfad und jede abgelehnte Anfrage als Warnung. Fehlgeschlagene Logins und nicht löschbare Bilddateien werden ebenfalls protokolliert. Ein strukturiertes Logging-Framework mit Correlation-Id ist noch nicht eingerichtet, die TraceId steckt aber bereits in jeder ProblemDetails-Antwort.

Health: GET /health ist da und prüft die Datenbankverbindung über die NpgsqlDataSource. Getestet, liefert Healthy.

CancellationToken: nur dort durchgereicht, wo es ohne Umbau ging, also Bild-Upload und AppInfo. Für die Repositories bräuchte jeder Dapper-Aufruf eine CommandDefinition. Das ist reine Fleißarbeit über rund 40 Aufrufstellen und bleibt offen, damit dieser Änderungssatz überschaubar bleibt.

Bleibt für den CancellationToken-Teil offen.

Branch backend/issue-fixes, Commits 2a1cc95, 026544c.

Teilweise erledigt. **Logging:** `ILogger` wird jetzt verwendet. Der zentrale Fehler-Handler loggt jeden 500er mit Stacktrace, Methode und Pfad und jede abgelehnte Anfrage als Warnung. Fehlgeschlagene Logins und nicht löschbare Bilddateien werden ebenfalls protokolliert. Ein strukturiertes Logging-Framework mit Correlation-Id ist noch nicht eingerichtet, die TraceId steckt aber bereits in jeder ProblemDetails-Antwort. **Health:** `GET /health` ist da und prüft die Datenbankverbindung über die `NpgsqlDataSource`. Getestet, liefert `Healthy`. **CancellationToken:** nur dort durchgereicht, wo es ohne Umbau ging, also Bild-Upload und AppInfo. Für die Repositories bräuchte jeder Dapper-Aufruf eine `CommandDefinition`. Das ist reine Fleißarbeit über rund 40 Aufrufstellen und bleibt offen, damit dieser Änderungssatz überschaubar bleibt. Bleibt für den CancellationToken-Teil offen. --- Branch `backend/issue-fixes`, Commits 2a1cc95, 026544c.