API-Limit block/notification & Error warnings

[dorvak]

Ein Großteil der Fehler der Facebook-API-Errors wurden durch die Überschreitung der Limits ("User request limit reached") verursacht. Hier könnte man in Zukunft eine Blockierung einführen, wenn die Limits bei Twitter/Facebook (die jeweils eindeutig durch eine Error-Message in den Metadaten gekennzeichnet sind) überschritten werden, Alternativ auch nur eine Warnung per ButtonDialog etc.

Gleiches gilt auch für "normale" Errormeldungen, z. B. wenn ein falsches/nicht existenter Endpoint gewählt wurde. Hier sollte man eventuell ein Limit einführen, des verhindert, dass x-tausend Anfragen mit derselben, fehlerhaften Einstellung generiert werden (d.h. Error-Messages im erhebungsprozess bereits parsen, einen Variable "errorcount" inkrementieren und ggf. abbrechen)

[strohne]

Gute Idee. Fehler werden ja nicht nur durch die Daten signalisiert, sondern auch durch die http status codes, insbesondere 404 und 500. Im Prinzip kann in unserem Fall alles außer code 200 als Fehler gewertet werden. Redirects u.ä. werden eh nicht befolgt.

Das wird im Code auch schon mitgezählt und im Abfragedialog angezeigt. Man müsste hier lediglich eine if-Bedingung einbauen, die die Abfrage abbricht, wenn die Fehlerrate zum Beispiel 10% überschreitet. Zu niedrig darf man m.E. aber nicht gehen (und auch nicht mit absoluten Grenzen), weil bei größeren Abfragen immer mit einer gewissen Fehlerrate gerechnet werden muss.

[dorvak]

Exakt, wir müssen auch nicht unbedingt zwingend abbrechen, sollten aber eine explizitere Warnung ab einer bestimmten Fehlerrate angeben, etwa durch ein Pop-Up etc. - wobei wir dann überlegen müssten, wie wir die im Hintergrund laufenden Threads behandeln, d.h. ob wir die anhalten, abbrechen und wiederaufnehmen etc. Lediglich bei Fehlern über x % sollten wir den Nutzern NICHT die Wahl lassen und hier rigoros abbrechen, denn wenn jemand 50k fehlerhafte Anfragen macht hört der Spaß auf ^^)

Bzgl. der API-Limits von Facebook und Twitter gibt es ja auch konkrete Timeouts, die man mit einbauen könnte. Wenn von Twitter also für Endpoint XY eine Timeout-Fehler kommt könnte man diese Anfrage gegen den Endpoint für die entsprechende zeit verhinden (Nachteil: Wenn sich die Timeouts ändern müssten wir es wieder in einer neuen Version ändern - alternativ können wir solche allgemeinen Einstellungen natürlich auch dauerhaft online hinterlegen, so wie etwa die Hilfe. Das gilt übrigens auch für die Mouseover-Hinweise etc.: Wenn sich der FP die jedesmal beim Start versucht zu ziehen, können wir hier leichter Updates einspielen, ohne direkt ein striktes Client-Server-Regime aufzubauen oder uns um irgendwelche Auto-Updates (https://pypi.python.org/pypi/esky) kümmern zu müssen)

2015-02-04 12:13 GMT+01:00 strohne notifications@github.com:

Gute Idee. Fehler werden ja nicht nur durch die Daten signalisiert, sondern auch durch die http status codes, insbesondere 404 und 500. Im Prinzip kann in unserem Fall alles außer code 200 als Fehler gewertet werden. Redirects u.ä. werden eh nicht befolgt.

Das wird im Code auch schon mitgezählt und im Abfragedialog angezeigt. Man müsste hier lediglich eine if-Bedingung einbauen, die die Abfrage abbricht, wenn die Fehlerrate zum Beispiel 10% überschreitet. Zu niedrig darf man m.E. aber nicht gehen (und auch nicht mit absoluten Grenzen), weil bei größeren Abfragen immer mit einer gewissen Fehlerrate gerechnet werden muss.

— Reply to this email directly or view it on GitHub https://github.com/strohne/Facepager/issues/32#issuecomment-72837890.

[strohne]

Mir ist gerade eingefallen, dass wir eine Fehlersperre eigentlich schon irgendwann mal eingebaut hatten. Allerdings: da war ein Fehler in der Fehlersperre ;) Habe ich korrigiert, siehe letzten commit und https://github.com/strohne/Facepager/blob/master/src/actions.py#L476

Ich würde das nicht API-spezifisch machen. Das ist funktional gar nicht nötig und jede Änderung der API würde eine Änderung in Facepager nach sich ziehen müssen.

Wir sollten mal eine aktuellere Version als stable kennzeichnen, damit die auch genutzt wird.

Über die Hinterlegung der Hilfe-Texte auf github können wir mal weiter nachdenken. Ich hatte die von Facebook übrigens kürzlich für eine Lehrveranstaltung neu gezogen, müssten nur in unser Format überführt werden, schicke ich dir mal zu, vielleicht hast du ja Gelegenheit dazu.

[dorvak]

Hehe, das hatte ich auch nicht mehr im Kopf, obwohl ich mich an den Code-Kommentar erinnern konnte