---
id: PROJ-73
title: Restliche Crash-Härtung (Upload-Job-Status bei Panic, fehlende nil-Checks)
status: In Review
created: 2026-08-05
---

## Problem

Nach der großen Crash-Robustheit-Härtung (Commit 798cb28) sind zwei kleinere
Lücken bewusst offen geblieben:

1. `runUploadJob` (`internal/api/upload.go`) läuft jetzt zwar dank
   `internal/safego` nicht mehr prozessfatal bei einem Panic, der Job-Status
   bleibt aber dauerhaft auf `"running"` hängen — der Nutzer bekommt nie eine
   Fehlermeldung im Upload-UI, der Job wirkt wie ein hängender Prozess.
2. `internal/api/ocr_handlers.go:66` (`s.users.GetByUsername(...)`) und
   analoge Stellen dereferenzieren das Ergebnis ohne expliziten `u == nil`-
   Check. Aktuell liefert kein Store `(nil, nil)`, daher kein akuter Bug —
   aber ungeschützt gegen künftige Store-Implementierungen oder Refactorings.

## Lösung (Vorschlag)

1. In `runUploadJob`: `defer` einbauen, der bei `recover() != nil` den
   Job-Status auf `"error"` setzt (inkl. Fehlermeldung), statt nur zu loggen.
2. Alle `GetByUsername`-Aufrufstellen (grep `GetByUsername` über
   `internal/api/`) auf `if u == nil { ... }`-Guard nach dem `err == nil`-
   Check prüfen und ergänzen wo fehlend.

## Implementation Notes

**1. Upload-Job-Status bei Panic** — `internal/api/upload.go:148-162`

`runUploadJob` bekommt direkt nach `ctx := context.Background()` ein
`defer func(){ if rec := recover(); rec != nil { ... } }()`:
- setzt unter `job.mu` `Status = "error"` und `ErrMsg`,
- gibt den Panic anschließend per `panic(rec)` weiter, damit `safego.Run`
  ihn wie bisher mit Task-Namen loggt (Prozess bleibt stabil).

Bewusste Abweichung vom Spec-Vorschlag: die `ErrMsg` enthält **nicht** den
Panic-Wert, sondern den generischen Text „Import wegen eines internen Fehlers
abgebrochen". Ein Panic-Wert kann Fragmente von Mail-Inhalten transportieren
und `ErrMsg` wird über `/upload/progress/{jobID}` ans Frontend ausgeliefert
(DSGVO). Die Details stehen im Server-Log.

Feldnamen sind konsistent zum bestehenden Muster (`Status` "running"/"done"/
"error", `ErrMsg` mit JSON-Tag `error_msg`), `snapshot()` liefert sie bereits
unverändert ans Frontend — keine API-Änderung nötig.

**2. nil-Guards nach `GetByUsername`** — alle 13 Aufrufstellen in
`internal/api/`, jeweils nur die vorhandene `if err != nil`-Bedingung erweitert
(kein neuer Fehlerpfad, damit Statuscodes/Logging unverändert bleiben):

| Datei:Zeile | neue Bedingung |
|---|---|
| `restore_handlers.go:43`, `:140` | `err != nil \|\| user == nil` (500) |
| `search_handlers.go:429`, `:497` | `err != nil \|\| u == nil \|\| !mailBelongsToUser(...)` (403) |
| `export.go:373` | `err != nil \|\| u == nil \|\| !mailBelongsToUser(...)` (403) |
| `export.go:472` | `err != nil \|\| u == nil` (500) |
| `smtpout_handlers.go:103` | `err != nil \|\| u == nil \|\| u.Email == ""` (400) |
| `ocr_handlers.go:66` | `err != nil \|\| u == nil \|\| !mailBelongsToUser(...)` (403) |
| `auth_handlers.go:106` | `err != nil \|\| user == nil` (500) |
| `profile_handlers.go:36`, `:113`, `:183` | `err != nil \|\| user == nil` (500) |
| `ediscovery.go:134` | `err != nil \|\| u == nil` (500) |

Alle Pfade, die eine Zugriffsprüfung machen (Search/Export/OCR), fallen bei
`u == nil` auf „access denied" zurück, nicht auf „erlaubt" — fail-closed.

Lokal kein `go build` möglich (kein Go-Toolchain), nur statische Prüfung.

Deployed auf 132 am 2026-08-05.

## Acceptance Criteria

- [x] Upload-Job zeigt nach einem simulierten Panic im Verarbeitungspfad
      Status `"error"` mit Fehlermeldung statt dauerhaft `"running"`.
- [x] Alle `GetByUsername`-Stellen in `internal/api/` haben einen
      expliziten nil-Guard.
- [ ] `go build ./... && go vet ./...` auf 132 fehlerfrei für geänderte
      Dateien.