Retries für Summary überprüfen und ggf. fixen

Als Entwickli will ich prüfen, ob die Retry-Logik in async_post() korrekt implementiert ist, bzw. ob das Verhalten tatsächlich so von uns gewünscht ist, um einen evtl. Bug zu beheben.

Problemstellung:

  • großes Dokument soll zusammengefasst werden
  • Parser schafft Aufgabe nicht in Timeout
  • Summary stellt fest: "oh, Timeout!" Ich sage Core Bescheid
  • Core stellt fest: "oh, Timeout!", ich versuch es einfach nochmal
  • erneute Anfrage an Summary
  • das passiert sehr oft und scheint nicht mit der eingestellten Anzahl von Retries zusammenzuhängen. Ich habe überall 3 stehen, sehe aber viel mehr Versuche in den Logs.
  • User ist während der ganzen Zeit im ungewissen, da Frontend keinen Fehler ausgibt (s. Screenshot unten). Erst ganz am Ende kommt eine Fehlermeldung. Vermutlich weil das globale Timeout dann einsetzt.

Logs (DEBUG) für Core, Summary und Parser angehängt. Warum hört Parser-Log 13:40 auf und die anderen erst 13:56? Evtl. ein Hinweis

Akzeptanzkriterien

  • connection_timeout wurde für Parser von außen steuerbar gemacht (summary#20 (closed))
  • Lösungsideen wurden im Team besprochen und sich auf eine geeinigt
  • Lösung wurde umgesetzt und User wird nicht mehr unnötig warten gelassen.
  • Review einer zweiten Person durchgeführt

core.log summary.log parser.log

Frontend zeigt während der gesamten Zeit den "Ladebalken", nicht die Fehlermeldung. Die kommt erst ganz am Ende nach 5 Retries:

3CE5DE75-3597-4F37-B63C-C146790EC9F7

Edited by Robert Brunngräber
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information