Absturz nach Abschließen eines Kodierjobs

[schumaki]

Beschreibung

Nachdem ich einen Kodierjob abgeschlossen habe, sind keine Kodierjobs und Arbeitsbereiche auf dem Server mehr sichtbar. Das betrifft auch andere User und andere Arbeitsbereiche auf dem Server.

Woher der Fehler kommt, ist unklar.

Reproduktionsschritte

Schritte zum Nachstellen des Verhaltens:

Ich habe davor:

1. Im Firefox als Studienmanager gearbeitet
2. mich parallel in einem privaten Tab mit einem Test-Kodierer-Login eingelogt
3. Einen Kodierjob bis zum Ende kodiert
4. Im PopUp auf "Kodierjob abschließen" geklickt -> das PopUp hat sich nicht geschlossen
5. Den Tab manuell geschlossen und zurück gewechselt zum Tab "Meine Kodierjobs"

Dort ist die Ansicht:

6. Das private Fenster geschlossen -> In der Ansicht als Studienmanager kam nach Neuladen des Tabs diese Ansicht:

7. Firefox neugestartet, anderen Browser (Edge), anderen PC (Remote) probiert -> Anmeldung ist möglich, aber Arbeitsbereiche laden nicht mehr

Heute Vormittag hatte ich das selbe Problem auf dem Testserver, nach einigem Warten war dort aber wieder alles verfügbar. Lt. @jurei733 gab es dabei in den Logs keine dauerhaften Fehler.

Beispiele

• KKS Testbereich auf dem Produktivserver
• VERA_3_Test auf dem Testserver

---

Versionen

• Kodierboxversion 1.16.1
• Betriebssystem: Win11
• Browser: Firefox 151.0.4

[schumaki]

Update: Jetzt ist auf dem Produktiv-Server wieder alles da.
Diesmal hat es aber länger gedauert als heute Vormittag.

[jurei733]

Kurze Fehleranalyse:

Der sichtbare Zustand Arbeitsbereiche werden geladen... ist sehr wahrscheinlich ein Folgeeffekt: Im Browser blieb keycloak-login/Auth-Bootstrap pending, weshalb die Arbeitsbereiche nicht geladen wurden. Auslöser scheint der Abschluss eines Kodierjobs zu sein. Dabei wurde im Replay-Frontend vor dem Submit noch einmal saveAllCodingProgress ausgeführt und damit potentiell sehr viele Fortschritts-Saves parallel an das Backend geschickt.

Backendseitig laufen diese Progress-Saves transaktional und mit Row-Locking. Bei größeren Kodierjobs kann das den DB-/Backend-Pool stark blockieren, sodass danach auch eigentlich unabhängige Requests wie Login oder Arbeitsbereichsladen hängen. Dass keine selbstständige Erholung eingetreten ist und die Docker-Anwendung neu gestartet werden musste, spricht eher für festhängende/erschöpfte Backend- oder DB-Ressourcen als nur für eine kurze Lastspitze. Das passt weiterhin zum beobachteten Verhalten: Popup schließt nicht, anschließend leere/ladende Kodierjob- und Arbeitsbereichsansichten, Wiederherstellung erst nach Neustart.

Ein Draft-PR ist vorbereitet, der beim Abschließen und Job-Wechsel nur noch auf bereits ausstehende Row-Saves wartet und keinen Bulk-Resave aller Fortschritte mehr auslöst.

[jurei733]

Der Fix dafuer ist mit #757 in develop gemerged.

Die Aenderung beseitigt den vermuteten Last-/Lock-Ausloeser beim Abschluss eines Kodierjobs: Vor dem Submit wird jetzt nicht mehr saveAllCodingProgress ausgefuehrt, das bei groesseren Jobs alle Fortschritte noch einmal parallel ans Backend schicken konnte. Stattdessen wartet das Frontend nur noch auf bereits ausstehende zeilenbezogene Saves (flushPendingRowMutations) und bricht den Submit ab, falls dabei ein Save fehlschlaegt. Dasselbe Flush-Verhalten wird auch beim Wechsel zwischen Kodierjobs verwendet, damit auch dort kein Bulk-Resave mehr ausgeloest wird.

Damit sollte der beobachtete Effekt, dass nach dem Abschluss eines grossen Kodierjobs Backend-/DB-Ressourcen blockieren und danach Login bzw. Arbeitsbereichsladen haengen, adressiert sein. Wichtig: Der Fix ist auf develop gemerged; ob er auf dem betroffenen Server schon wirksam ist, haengt vom Deployment ab. Ich wuerde den Issue nach Deployment/Retest schliessen, sofern das Verhalten nicht erneut auftritt.