Hallo zusammen,
Ich hab einen Call zu Lexoffice, welcher auf Fehler läuft und folgende Fehlermeldung im Output:
HTTP status: 400 (Bad Request), Response Content: { „timestamp“ : „2024-09-XXX674+02:00“, „status“ : 400, „error“ : „Bad Request“, „path“: „/v1/invoices“, „traceId“: „a9XXX05“, „requestId“: „bd4c2XXXc0f06e72“, "mess…
Der wirklich interessante Part der Fehlermeldung fehlt leider aufgrund der Kürzung.
Ich bin mir nicht sicher, ob ihr den Output kürzt oder das schon in der API seitens Lexoffice passiert. Wenn ihr dafür verantwortlich seid, könnte man das vielleicht anpassen?
Gruß
Gustav
2 „Gefällt mir“
Hallo,
ich wollte hier das Thema nochmal pushen, könnt ihr da irgendwas machen?
Hier noch ein aktuelles Beispiel grade aus Plenty.
HTTP status: 400 (Bad Request), Response Content: {„code“:„product_invalid_sku“,„message“:„\u041d\u0435\u0432\u0430\u043b\u0438\u0434\u0435\u043d \u0438\u043b\u0438 \u0434\u0443\u0431\u043b\u0438\u0440\u0430\u043d \u043a\u043e\u0434.“,„data“:{"status…
In dem Fall ist zwar Message & Code ausreichend, um den Fehler zu verstehen. Aber das ist ja reiner Zufall. Was spricht dagegen, die gesamte Fehlermeldung darzustellen?
Gruß
Gustav
1 „Gefällt mir“
BUMP. Dritter Versuch 
, wo ich grade wieder eine sehr (un!)passend abgeschnittene Fehlermeldung hatte.
Hi Gustav,
Ich versuche es mal zu erklären:
Das Problem ist, das wir beim SpreadsheetUrlDownload an der Stelle nicht wissen, was als (Fehler) response ankommt. Es kann eine kurze JSON Response sein, ggf. aber auch sehr große HTML Antworten oder ähnliches.
Vor längerer Zeit haben wir die Log Einträge ungekürzt ausgegebenen und festgestellt das es Log Einträge der SpreadsheetUrlDownload Steps mit mehreren MB gibt. Das kann sich unter Umständen sehr schnell zu einer großen Datenmenge aufsummieren und zu einem Problem werden.
Wir haben uns deshalb dazu entschieden die Log Einträge im Eventlog gekürzt (und nur im debug log vollständig) auszugeben. Aktuell werden die log Einträge auf max. 200 Zeichen begrenzt ausgegeben. Selbst wenn wir das Zeichenlimit etwas erhöhen, wird es immer noch „unpassend“ abgeschnittene Einträge geben, da nie klar ist wo der relevante/„interessante“ Teil der Fehlermeldung steht.
Wir haben das auch intern länger diskutiert, aber sind zu keiner sinnvollen Lösung gekommen, wie wir einen hilfreicheren, aber gekürzten Log Eintrag erzeugen können.
→ Ideen sind willkommen
VG Torsten
1 „Gefällt mir“
Hallo Torsten,
danke für die Antwort. Ich habe schon vermutet, dass dort das Problem liegt.
Dass ihr das daher irgendwie limitieren müsst, ist verständlich. Ich glaube aber, dass ihr mit 200 Zeichen ein bisschen zu strikt seid. Denke, dass ein Limit von 1000 oder gar 2000 Zeichen würde in sehr sehr vielen Fällen eine ausreichende Fehlermeldung liefern würde und diese Problematik sehr häufig schon erledigt.
In meinem Beispiel vom November gehen beispielsweise schon 50 Zeichen einfach nur für den HTTP-Status drauf. Da ist ein Viertel der Zeichen schon verbraucht, bevor die tatsächliche Fehlermeldung überhaupt los geht. Klar wird es weiterhin problematische Fälle geben, aber deutlich seltener.
Ansonsten wäre meine Idee, die vollständige Fehlermeldung irgendwie in den Debug-Modus zu integrieren. Dass bei aktivem Debugging die Fehlermeldungen in eine Datei geschrieben werden und zum Download bereitgestellt werden. Eigentlich macht das ja der Debug-Log auch schon. Vielleicht kann man ja einen abgespeckten und einfacher lesbaren Debuglog weiterhin für den Anwender zur Verfügung stellen?
Weniger ernst gemeinter Alternative: Lasst die ganze Fehlermeldung von einem LLM auf maximal XXX Zeichen zusammenfassen.
Gruß
Gustav
Hallo @synesty-Torsten,
wäre das mit dem Debuglog eine mögliche Option?
Im Moment stolpert man immer wieder über eine verkürzte Fehlermeldung. Ob die Fehlermeldung nun irgendeinen Aufschluss über die Fehlerursache gibt, kriegt man nur raus, indem man die ganze Request in Postman oder ähnlichem nachbaut und dort den Fehler anschaut.
Gruß
Gustav
Hi Gustav,
bei den 4 Steps
wird das Debuglog vollständig geschrieben und es kann auch von Anwendern heruntergeladen werden. D.h. darin sollte auch die vollständige Fehlermeldung aus dem SpreadsheetUrlDownload Step vorhanden sein.
VG Torsten
1 „Gefällt mir“
Hallo @synesty-Torsten,
sehr cool, danke! Habs gleich mal getestet und klappt wie erwartet. Natürlich endete die Fehlermeldung mit:
"ErrorMessage":null}
Das ist zwar keineswegs zufriedenstellend, aber schonmal um Welten besser als
"ErrorMessage":...
Gruß
Gustav