50 lines
1.7 KiB
Markdown
50 lines
1.7 KiB
Markdown
# Design: Reorder-Validierung im PlaylistStore
|
|
|
|
**Datum:** 2026-03-26
|
|
**Scope:** `store.go` (Reorder), `manage/ui.go` (HandleReorderUI), `manage/playlist.go` (HandleReorder)
|
|
|
|
## Problem
|
|
|
|
`PlaylistStore.Reorder` akzeptiert beliebige ID-Listen ohne Prüfung:
|
|
|
|
- Unbekannte oder fremde IDs werden stillschweigend ignoriert (0 Rows affected, kein Fehler)
|
|
- Eine Teilliste korrumpiert die Sortierung: nicht geschickte Items behalten ihren alten `order_index`
|
|
- Beide Fehlerszenarien sind für den Client unsichtbar — der Response ist trotzdem 204
|
|
|
|
## Lösung
|
|
|
|
### 1. Sentinel-Fehler in `store.go`
|
|
|
|
```go
|
|
var ErrReorderMismatch = errors.New("reorder: item list does not match playlist")
|
|
```
|
|
|
|
### 2. Vollständigkeitsprüfung in `Reorder`
|
|
|
|
Vor den Updates: `COUNT(*)` der Items in der Playlist innerhalb der Transaktion.
|
|
Wenn `len(itemIDs) != count` → `ErrReorderMismatch` zurückgeben.
|
|
|
|
### 3. RowsAffected-Check pro Update
|
|
|
|
Nach jedem `tx.Exec`: wenn `RowsAffected() != 1` → `ErrReorderMismatch` zurückgeben.
|
|
(Fängt fremde IDs, die die `AND playlist_id=`-Bedingung passiert hätten.)
|
|
|
|
### 4. Handler-Anpassung (400 statt 500)
|
|
|
|
Beide Handler prüfen `errors.Is(err, store.ErrReorderMismatch)`:
|
|
- Match → `http.StatusBadRequest` (400)
|
|
- Sonst → `http.StatusInternalServerError` (500)
|
|
|
|
## Verhalten nach Fix
|
|
|
|
| Szenario | Vorher | Nachher |
|
|
|---|---|---|
|
|
| Vollständige, korrekte Liste | 204 ✓ | 204 ✓ |
|
|
| Teilliste | 204 (stille Korruption) | 400 → UI reloaded |
|
|
| Fremde/unbekannte ID | 204 (still ignoriert) | 400 → UI reloaded |
|
|
| DB-Fehler | 500 | 500 |
|
|
|
|
## Nicht im Scope
|
|
|
|
- Änderung des Drag&Drop-Frontends (schickt bereits die vollständige Liste)
|
|
- Neue Tests (werden im Implementierungsplan ergänzt falls vorhanden)
|