Bug: Race Condition bei gleichzeitigem Ticket-Enrichment #38

New issue

Open

opened 2026-03-30 19:54:16 +00:00 by David · 0 comments

David commented

2026-03-30 19:54:16 +00:00

Collaborator

Beschreibung

Wenn zwei User gleichzeitig dasselbe Ticket enrichen, überschreibt der letzte Commit die Änderungen des ersten. Kein Row-Level Locking vorhanden.

Hintergrund

tickets.py:134-146 liest das Ticket, modifiziert Felder und committed — ohne Locking. Bei zwei parallelen PATCH-Requests auf dasselbe Ticket gehen Daten des ersten Users verloren (Last-Write-Wins).

Akzeptanzkriterien

Optimistic Locking via Version-Counter oder SELECT ... FOR UPDATE
Bei Conflict: HTTP 409 mit klarer Fehlermeldung an den User
Frontend zeigt Conflict-Warnung wenn Enrichment fehlschlägt
Test der Race Condition mit parallelen Requests

Technische Hinweise

Fix in: backend/api/tickets.py:134-146
Option A: Optimistic Locking — version Feld im Ticket-Model, bei jedem Update incrementieren, bei Mismatch 409
Option B: Pessimistic Locking — db.query(Ticket).with_for_update().filter(...)
Erweitern: backend/models/ticket.py — optional version Feld (Integer)
Migration nötig: ja (wenn Optimistic Locking mit Version-Feld)

Aufwand: S

## Beschreibung Wenn zwei User gleichzeitig dasselbe Ticket enrichen, überschreibt der letzte Commit die Änderungen des ersten. Kein Row-Level Locking vorhanden. ## Hintergrund `tickets.py:134-146` liest das Ticket, modifiziert Felder und committed — ohne Locking. Bei zwei parallelen PATCH-Requests auf dasselbe Ticket gehen Daten des ersten Users verloren (Last-Write-Wins). ## Akzeptanzkriterien - [ ] Optimistic Locking via Version-Counter oder `SELECT ... FOR UPDATE` - [ ] Bei Conflict: HTTP 409 mit klarer Fehlermeldung an den User - [ ] Frontend zeigt Conflict-Warnung wenn Enrichment fehlschlägt - [ ] Test der Race Condition mit parallelen Requests ## Technische Hinweise - Fix in: `backend/api/tickets.py:134-146` - Option A: Optimistic Locking — `version` Feld im Ticket-Model, bei jedem Update incrementieren, bei Mismatch 409 - Option B: Pessimistic Locking — `db.query(Ticket).with_for_update().filter(...)` - Erweitern: `backend/models/ticket.py` — optional `version` Feld (Integer) - Migration nötig: ja (wenn Optimistic Locking mit Version-Feld) ## Aufwand: S