Synchronisierungs-Prozess

Dieses Dokument beschreibt den Prozess der Datensynchronisierung zwischen App (Client) und Server (Syncbox), insbesondere wie Updates für bestehende Einträge behandelt werden.

Ablaufdiagramm

  sequenceDiagram
    participant Client
    participant Server
    participant DB

    Client->>Client: Sammle nicht-synchronisierte Berichte (is_synced=0)
    Client->>Server: POST /sync (JSON Payload)
    
    loop Für jedes Element (Bericht, Zone, etc.)
        Server->>DB: Suche nach UUID
        
        alt Existiert bereits (UUID Treffer)
            DB-->>Server: Eintrag gefunden
            Server->>DB: UPDATE aller Felder (Status, Notizen, etc.)
            Note right of Server: KEIN "Fast Exit".<br/>Änderungen (z.B. Status "geschnitten")<br/>werden übernommen.
        else Existiert nicht
            DB-->>Server: Nicht gefunden
            Server->>DB: INSERT Neuer Eintrag
        end
    end
    
    Server-->>Client: 200 OK (Erfolgreich)
    Client->>Client: Markiere lokal als synchronisiert (is_synced=1)

Erklärung zum “Fast Exit” Problem

Es wurde ein potenzielles Problem identifiziert, bei dem Updates für bereits existierende Einträge (z.B. Statusänderung auf “geschnitten”) vom Server ignoriert wurden, wenn dieser einen “Fast Exit” bei bekannter UUID durchführte (d.h. die Verarbeitung abbrach, weil der Eintrag schon da war).

Lösung: Der Server-Code (api_v1.py) wurde überprüft und sichergestellt, dass immer ein Update (UPDATE) durchgeführt wird, wenn die UUID bereits existiert. Es gibt keinen vorzeitigen Abbruch. Die Felder aus dem Payload (wie status, updated_at) überschreiben die Werte in der Datenbank.

Wichtig für Entwickler

• Die Methode upsert_item im Backend erzwingt das Update:

  if existing:
      # UPDATE existing item (No Fast Exit)
      for key, value in filtered_data.items():
          setattr(existing, key, value)
• Der Client sendet den Status als String (z.B. “geschnitten”).