Debugging¶

Diese Seite beschreibt, wie das Backend und das Frontend in der lokalen Entwicklungsumgebung debuggt werden. Alle Methoden setzen ein laufendes Skaffold-Setup voraus (siehe Lokales Setup).

Backend-Debugging mit debugpy¶

Das Backend-Container-Image enthält debugpy — den Python-Debugger, den VS Code, PyCharm und andere IDEs für Remote-Debugging verwenden.

Debug-Modus starten¶

skaffold debug --port-forward

Das debug-Profil in skaffold.yaml setzt DEBUGPY_ENABLED=true als Docker-Build-Argument. Der Container startet daraufhin debugpy und wartet optional auf eine Verbindung.

Debugpy lauscht auf Port 5678. Skaffold leitet diesen Port nicht automatisch weiter — das muss manuell eingerichtet werden:

kubectl port-forward deployment/kamerplanter-backend 5678:5678

VS Code — launch.json¶

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Kamerplanter Backend (Remote)",
      "type": "debugpy",
      "request": "attach",
      "connect": {
        "host": "localhost",
        "port": 5678
      },
      "pathMappings": [
        {
          "localRoot": "${workspaceFolder}/src/backend",
          "remoteRoot": "/app"
        }
      ],
      "justMyCode": true
    }
  ]
}

PyCharm — Remote-Debug-Konfiguration¶

1. Menü: Run → Edit Configurations → + → Python Debug Server
2. Host: localhost, Port: 5678
3. Path Mappings: src/backend/app → /app/app
4. Konfiguration starten, dann skaffold debug --port-forward ausführen

Breakpoints und Log-Ausgabe¶

Der Backend-Server läuft mit uvicorn im --reload-Modus. Strukturierte Logs werden über structlog ausgegeben:

import structlog

log = structlog.get_logger()

async def create_species(data: CreateSpeciesRequest) -> Species:
    log.info("creating_species", scientific_name=data.scientific_name)
    # Breakpoint hier setzen
    result = await self.repo.create(data)
    log.info("species_created", key=result.key)
    return result

Pod-Logs einsehen¶

Ohne Debugger reichen oft die Logs aus:

# Backend-Logs (letzte 100 Zeilen, dann live folgen)
kubectl logs -l app=kamerplanter-backend --tail=100 -f

# Celery-Worker-Logs
kubectl logs -l app=kamerplanter-worker --tail=100 -f

# Nur Fehler
kubectl logs -l app=kamerplanter-backend --tail=200 | grep '"level":"error"'

Frontend-Debugging¶

Browser DevTools¶

Die meisten Frontend-Probleme lassen sich mit den Browser-Entwicklerwerkzeugen lösen:

• Konsole (F12 → Console): JavaScript-Fehler, unbehandelte Promise-Rejections, i18n-Warnungen zu fehlenden Schlüsseln
• Netzwerk (F12 → Network): API-Anfragen, HTTP-Status-Codes, Request/Response-Bodies
• Redux DevTools: Redux-Zustandsänderungen nachverfolgen (Erweiterung für Chrome/Firefox erforderlich)

React Developer Tools¶

Die React DevTools Browser-Erweiterung ermöglicht: - Komponenten-Baum inspizieren - Props und State einzelner Komponenten einsehen - Re-Render-Profiler für Performance-Analyse

Vite-Quellkarten¶

Im Entwicklungsmodus (Vite Dev Server, Port 5173) sind Quellkarten aktiv. Haltepunkte können direkt in TypeScript-Dateien im Browser-Debugger gesetzt werden.

Häufige Frontend-Probleme¶

ArangoDB Web-UI¶

Die ArangoDB-Weboberfläche ist unter http://localhost:8529 erreichbar:

Nützliche AQL-Abfragen für die Fehlersuche:

// Alle Pflanzenarten anzeigen
FOR s IN species RETURN s

// Verbindungen eines Mandanten prüfen
FOR v, e IN 1..1 OUTBOUND 'tenants/demo' GRAPH 'kamerplanter_graph'
  RETURN { vertex: v._id, edge: e._from }

// Letzte 10 Aufgaben
FOR t IN tasks
  SORT t.created_at DESC
  LIMIT 10
  RETURN t

Celery-Aufgaben debuggen¶

Für Hintergrundaufgaben (Celery Beat + Worker) sind separate Logs vorhanden:

# Celery-Worker
kubectl logs -l app=kamerplanter-worker -f

# Celery-Beat (Scheduler)
kubectl logs -l app=kamerplanter-beat -f

Eine Aufgabe manuell auslösen (direkter Python-Aufruf im Backend-Pod):

kubectl exec -it deployment/kamerplanter-backend -- python -c "
from app.tasks.care_reminders import generate_due_care_reminders
result = generate_due_care_reminders.delay()
print('Task ID:', result.id)
"

Health-Endpunkte¶

Das Backend stellt zwei Health-Endpunkte bereit, die auch für manuelle Diagnosen nützlich sind:

# Liveness (läuft der Prozess?)
curl http://localhost:8000/api/v1/health/live

# Readiness (ist die Datenbank erreichbar?)
curl http://localhost:8000/api/v1/health/ready

Erwartete Antwort (beide): {"status": "ok"} mit HTTP 200.

Häufige Fehlerszenarien¶

kubectl logs <backend-pod-name> -c init-seed

Siehe auch¶

• Lokales Setup
• Testen
• Code-Standards