Kritische Pipeline-Bugs: Falsches Approval, fehlende Dedup, Score-Overflow #70

New issue

Open

opened 2026-03-30 20:18:33 +00:00 by David · 0 comments

David commented

2026-03-30 20:18:33 +00:00

Collaborator

Beschreibung

Mehrere kritische Bugs in der Pipeline führen dazu, dass ungeprüfter Code
automatisch approved wird, doppelte MRs erstellt werden und Scoring-Werte
außerhalb der definierten Grenzen liegen.

Hintergrund

Code-Review der Pipeline-Services hat 6 kritische/hohe Findings ergeben,
die alle die Korrektheit der automatischen Verarbeitung betreffen.
Diese Bugs können dazu führen, dass fehlerhafter Code in Produktion landet.

Findings

1. Review Agent: Approval-Parsing fragil (CRITICAL)

Datei: backend/services/review_agent.py Zeile 112, 179

approved = "APPROVED" in review_text.upper().split("CHANGES_REQUESTED")[0]

Findet "APPROVED" in falschen Abschnitten (z.B. Zusammenfassung statt Bewertung)
Fix: Regex oder Section-Parser, der nur im ## Bewertung-Abschnitt sucht

2. Review Agent: Timeout/Error = Auto-Approve (CRITICAL)

Datei: backend/services/review_agent.py Zeile 122-127, 184-189

except asyncio.TimeoutError:
    return {"approved": True, "review": "Review-Timeout — übersprungen."}

Timeout und Exceptions geben approved: True zurück
Fix: approved: False bei jedem Fehlerfall, manuelle Review erforderlich

3. Review Agent: Diff-Truncation schneidet mitten in Zeile (CRITICAL)

Datei: backend/services/review_agent.py Zeile 82-83, 151-152

if len(diff_content) > 15000:
    diff_content = diff_content[:15000] + "\n\n... (Diff gekürzt)"

Schneidet mitten in Diff-Hunks → Claude reviewt unvollständigen Code
Fix: An Zeilengrenzen schneiden, bei zu großem Diff approved: False zurückgeben

4. Pipeline: `_running`-Set nicht thread-safe (CRITICAL)

Datei: backend/services/pipeline.py Zeile 73-77

if ticket_id in self._running:
    return
self._running.add(ticket_id)

Check-then-add ohne Lock → zwei Tasks können gleichzeitig starten
Fix: asyncio.Lock() um Check-and-Add

5. Scoring: LLM-Scores nicht geclampt (CRITICAL)

Datei: backend/services/scoring_engine.py Zeile 191-205

LLM kann Werte >100 oder <0 zurückgeben → Score >60 möglich
Bricht Klassifikations-Schwellwerte (autopilot/klärfall/abgelehnt)
Fix: max(0, min(100, score)) pro Komponente, max(0, min(60, result)) am Ende

6. GitLab: Kein MR-Dedup im manuellen Endpoint (HIGH)

Datei: backend/api/tickets.py Zeile 236-292 + backend/services/gitlab_service.py Zeile 42-109

Mehrfach-Klick auf "MR erstellen" erzeugt mehrere MRs
Kein Check auf existierende MRs für denselben Branch
Fix: Vor MR-Erstellung prüfen ob ticket.mr_id gesetzt oder offener MR für Branch existiert

Akzeptanzkriterien

Review Agent gibt bei Timeout/Error approved: False zurück
Approval-Parsing sucht nur im Bewertungs-Abschnitt nach APPROVED/CHANGES_REQUESTED
Diff-Truncation schneidet an Zeilengrenzen, gibt bei >15KB approved: False zurück
_running-Set wird mit asyncio.Lock() geschützt
LLM-Scores werden auf 0-100 pro Komponente und 0-60 gesamt geclampt
Manuelle MR-Erstellung prüft auf existierende MRs und verhindert Duplikate
Tests: Review-Approval-Parsing mit Edge Cases (Preamble, falsche Abschnitte)
Tests: Score-Clamping mit Werten >100, <0, und Normalwerten
Tests: MR-Dedup bei doppeltem Aufruf

Technische Hinweise

Betroffene Dateien:
- backend/services/review_agent.py (Approval-Logik, Timeout-Handling, Diff-Truncation)
- backend/services/pipeline.py (_running Lock + __init__)
- backend/services/scoring_engine.py (_calculate_llm_score)
- backend/services/gitlab_service.py (create_mr Dedup-Check)
- backend/api/tickets.py (manueller MR-Endpoint)
Ansatz: Gezielte Fixes in bestehenden Methoden, kein Refactoring nötig
Migration nötig: Nein

Aufwand: M

## Beschreibung Mehrere kritische Bugs in der Pipeline führen dazu, dass ungeprüfter Code automatisch approved wird, doppelte MRs erstellt werden und Scoring-Werte außerhalb der definierten Grenzen liegen. ## Hintergrund Code-Review der Pipeline-Services hat 6 kritische/hohe Findings ergeben, die alle die Korrektheit der automatischen Verarbeitung betreffen. Diese Bugs können dazu führen, dass fehlerhafter Code in Produktion landet. ## Findings ### 1. Review Agent: Approval-Parsing fragil (CRITICAL) **Datei:** `backend/services/review_agent.py` Zeile 112, 179 ```python approved = "APPROVED" in review_text.upper().split("CHANGES_REQUESTED")[0] ``` - Findet "APPROVED" in falschen Abschnitten (z.B. Zusammenfassung statt Bewertung) - **Fix:** Regex oder Section-Parser, der nur im `## Bewertung`-Abschnitt sucht ### 2. Review Agent: Timeout/Error = Auto-Approve (CRITICAL) **Datei:** `backend/services/review_agent.py` Zeile 122-127, 184-189 ```python except asyncio.TimeoutError: return {"approved": True, "review": "Review-Timeout — übersprungen."} ``` - Timeout und Exceptions geben `approved: True` zurück - **Fix:** `approved: False` bei jedem Fehlerfall, manuelle Review erforderlich ### 3. Review Agent: Diff-Truncation schneidet mitten in Zeile (CRITICAL) **Datei:** `backend/services/review_agent.py` Zeile 82-83, 151-152 ```python if len(diff_content) > 15000: diff_content = diff_content[:15000] + "\n\n... (Diff gekürzt)" ``` - Schneidet mitten in Diff-Hunks → Claude reviewt unvollständigen Code - **Fix:** An Zeilengrenzen schneiden, bei zu großem Diff `approved: False` zurückgeben ### 4. Pipeline: `_running`-Set nicht thread-safe (CRITICAL) **Datei:** `backend/services/pipeline.py` Zeile 73-77 ```python if ticket_id in self._running: return self._running.add(ticket_id) ``` - Check-then-add ohne Lock → zwei Tasks können gleichzeitig starten - **Fix:** `asyncio.Lock()` um Check-and-Add ### 5. Scoring: LLM-Scores nicht geclampt (CRITICAL) **Datei:** `backend/services/scoring_engine.py` Zeile 191-205 - LLM kann Werte >100 oder <0 zurückgeben → Score >60 möglich - Bricht Klassifikations-Schwellwerte (autopilot/klärfall/abgelehnt) - **Fix:** `max(0, min(100, score))` pro Komponente, `max(0, min(60, result))` am Ende ### 6. GitLab: Kein MR-Dedup im manuellen Endpoint (HIGH) **Datei:** `backend/api/tickets.py` Zeile 236-292 + `backend/services/gitlab_service.py` Zeile 42-109 - Mehrfach-Klick auf "MR erstellen" erzeugt mehrere MRs - Kein Check auf existierende MRs für denselben Branch - **Fix:** Vor MR-Erstellung prüfen ob `ticket.mr_id` gesetzt oder offener MR für Branch existiert ## Akzeptanzkriterien - [ ] Review Agent gibt bei Timeout/Error `approved: False` zurück - [ ] Approval-Parsing sucht nur im Bewertungs-Abschnitt nach APPROVED/CHANGES_REQUESTED - [ ] Diff-Truncation schneidet an Zeilengrenzen, gibt bei >15KB `approved: False` zurück - [ ] `_running`-Set wird mit `asyncio.Lock()` geschützt - [ ] LLM-Scores werden auf 0-100 pro Komponente und 0-60 gesamt geclampt - [ ] Manuelle MR-Erstellung prüft auf existierende MRs und verhindert Duplikate - [ ] Tests: Review-Approval-Parsing mit Edge Cases (Preamble, falsche Abschnitte) - [ ] Tests: Score-Clamping mit Werten >100, <0, und Normalwerten - [ ] Tests: MR-Dedup bei doppeltem Aufruf ## Technische Hinweise - Betroffene Dateien: - `backend/services/review_agent.py` (Approval-Logik, Timeout-Handling, Diff-Truncation) - `backend/services/pipeline.py` (`_running` Lock + `__init__`) - `backend/services/scoring_engine.py` (`_calculate_llm_score`) - `backend/services/gitlab_service.py` (`create_mr` Dedup-Check) - `backend/api/tickets.py` (manueller MR-Endpoint) - Ansatz: Gezielte Fixes in bestehenden Methoden, kein Refactoring nötig - Migration nötig: Nein ## Aufwand: M