Bug: Polling-Deduplication fehlt — doppelte Ticket-Verarbeitung möglich #44

New issue

Closed

opened 2026-03-30 19:55:22 +00:00 by David · 1 comment

David commented

2026-03-30 19:55:22 +00:00

Collaborator

Beschreibung

Wenn der Odoo-Polling-Job länger dauert als das Polling-Intervall, startet der nächste Job parallel. Dasselbe Ticket kann doppelt verarbeitet werden.

Hintergrund

main.py:49-56 registriert den Polling-Job per APScheduler-Intervall (z.B. alle 5 Minuten). Wenn ein Job 6 Minuten dauert (z.B. viele neue Tickets, langsame Odoo-API), startet der nächste Job parallel. Beide verarbeiten dieselben neuen Tickets.

Akzeptanzkriterien

Polling-Job prüft ob bereits eine Instanz läuft (Lock-Mechanismus)
Bei laufendem Job: neuer Job wird übersprungen mit Log-Warnung
Lock wird auch bei Exceptions korrekt freigegeben
Gleiches Prinzip für AppSignal-Polling und Watchdog-Job
Test mit simuliertem langsamen Polling

Technische Hinweise

Fix in: backend/main.py — asyncio.Lock() oder threading.Lock() pro Scheduler-Job
Alternative: APScheduler max_instances=1 Parameter (einfachste Lösung)
Zusätzlich in Pipeline: Prüfung ob Ticket bereits in _running_tickets Set
Migration nötig: nein

Aufwand: S

## Beschreibung Wenn der Odoo-Polling-Job länger dauert als das Polling-Intervall, startet der nächste Job parallel. Dasselbe Ticket kann doppelt verarbeitet werden. ## Hintergrund `main.py:49-56` registriert den Polling-Job per APScheduler-Intervall (z.B. alle 5 Minuten). Wenn ein Job 6 Minuten dauert (z.B. viele neue Tickets, langsame Odoo-API), startet der nächste Job parallel. Beide verarbeiten dieselben neuen Tickets. ## Akzeptanzkriterien - [ ] Polling-Job prüft ob bereits eine Instanz läuft (Lock-Mechanismus) - [ ] Bei laufendem Job: neuer Job wird übersprungen mit Log-Warnung - [ ] Lock wird auch bei Exceptions korrekt freigegeben - [ ] Gleiches Prinzip für AppSignal-Polling und Watchdog-Job - [ ] Test mit simuliertem langsamen Polling ## Technische Hinweise - Fix in: `backend/main.py` — `asyncio.Lock()` oder `threading.Lock()` pro Scheduler-Job - Alternative: APScheduler `max_instances=1` Parameter (einfachste Lösung) - Zusätzlich in Pipeline: Prüfung ob Ticket bereits in `_running_tickets` Set - Migration nötig: nein ## Aufwand: S

David added the

bug

backend

wichtig

labels

2026-03-30 19:55:22 +00:00

David commented

2026-03-30 20:41:29 +00:00

Author

Collaborator

Superseded by #74 (Error Recovery & Cleanup). Die Cleanup-Logik für stuck Tickets und Resource Leaks ist dort vollständig abgedeckt (Finding #1, #8, #9).