Was möchten Sie erreichen?
Wir haben eine benutzerdefinierte Theme-Komponente (das „Bio Book"), die seit kurzem 429-Fehler zurückgibt. Dies begann am 26. November. Davor funktionierte es einwandfrei.
Das Bio Book manipuliert die Route /u, um Benutzerinformationen schöner darzustellen. Dafür forderte es zudem zusätzliche Benutzerinformationen aus der .json-Datei jedes Benutzers an. Das Bio Book nutzte ein Lazy-Loading, um 429-Fehler zu vermeiden, doch das funktioniert seit vier Tagen nicht mehr – ich bin mir nicht sicher, was vor vier Tagen passiert ist, aber das Discourse-Team hat bestätigt, dass keine Änderungen an den Rate Limits vorgenommen wurden.
Der Entwickler, der die Komponente ursprünglich für uns erstellt hat, steht für diese Korrektur nicht zur Verfügung. Daher benötigen wir jemanden, der in den bestehenden Code einsteigen und die Fehler beheben kann, damit die benutzerdefinierte Theme-Komponente wieder funktioniert.
Wir möchten keine neuen Funktionen, keine Änderungen an bestehenden Funktionen und auch keine Refaktorierung. Wir wollen lediglich die 429-Fehler beheben und das Bio Book wieder in seinen vorherigen Funktionszustand versetzen.
Bis wann muss es erledigt sein?
Wir wünschen die Fertigstellung bis Montag, den 6. Januar 2020.
Wie hoch ist Ihr Budget in USD für diese Aufgabe?
Unser Budget beträgt 250 $ für die Behebung der 429-Fehler.
Wir gehen davon aus, dass die Behebung der 429-Fehler alle zugrunde liegenden Probleme löst. Falls dies nicht der Fall ist, teilen Sie uns dies bitte mit, und wir werden unser Budget entsprechend anpassen.
Es lädt also in Gruppen von 50 Benutzern per lazy loading, und der Standardwert für max_reqs_per_ip_per_10_seconds ist ebenfalls auf 50 gesetzt. Einschließlich der Hauptseite führt dieser Code mindestens 51 Anfragen aus (in weniger als 10 Sekunden), wodurch das Ratenlimit überschritten wird.
Mit anderen Worten: Ich verstehe nicht, wie das vorher funktionieren konnte…?
Ich bin mir auch nicht sicher, wie das passiert ist, aber es funktionierte über ein Jahr lang einwandfrei. Bis vor vier Tagen hatten wir noch nie mit einem 429-Fehler zu tun.
Wir haben letzte Woche global für alle Discourse-Instanzen weltweit das Rate-Limit aktiviert. Nächste Woche können wir das Plugin untersuchen und prüfen, ob es eine sinnvolle Batch-API gibt, die es stattdessen nutzen kann.
Wow, ich bin vor kurzem aus einem sehr ähnlichen Grund auf genau dieses Problem gestoßen (Abrufen von Benutzerdaten zur Anzeige von Karten!). Ich habe vorübergehend einen kleinen Hack implementiert, um es zu beheben, und bin hierher ins Forum gekommen, um herauszufinden, ob es eine Batch-API gibt, die ich nicht kenne… oder um zu lernen, wie man so eine Route implementiert.
Entschuldigung, Alex, ich habe dich letzte Woche mit meiner Antwort im Unrecht gelassen. Mir war nicht klar, dass wir diese Änderung schon vor einiger Zeit nicht bereitgestellt hatten.
Ich warte mit diesem Projekt noch etwas ab, bis ich von @sam und dem Team höre, ob es eine vernünftige Batch-API gibt, die wir stattdessen nutzen können.
ich habe mir gerade die Theme-Komponente angesehen. Sie führt tatsächlich zu einer enormen Arbeitslast und einer großen Anzahl von Anforderungen. Die von uns implementierte Ratenbegrenzung ist hier als Immunsystem absolut richtig.
Wir werden das in Ordnung bringen, aber es könnte ein oder zwei Wochen dauern, bis alles erledigt ist.
Meiner Einschätzung nach liegt das Hauptproblem darin, dass das Verzeichnis nun alle Informationen zurückgeben muss, die Benutzerkarten enthalten. Das Tückische daran ist, dass Theme-Komponenten keine Möglichkeit haben, den Server zu ändern. Daher müssen wir eine Änderung an der Kern-API vornehmen, die es uns ermöglicht, Benutzerkarten für mehrere Personen auf einmal abzurufen.
Wir halten Sie auf dem Laufenden, sobald wir Fortschritte erzielen. Kurze Anmerkung zum Budget: Wir erledigen diese Aufgabe kostenlos, schätzen aber, dass etwa zwei Arbeitstage für die Reparatur nötig sind – das liegt weit über dem ursprünglichen Budget. Auf den ersten Blick scheint es einfach, erfordert jedoch sehr komplexe interne Änderungen.
Vielen Dank, @sam und Team, das ist unglaublich hilfreich. Die Änderungen an der Kern-API werden uns und vermutlich auch anderen Discourse-Nutzern sehr zugutekommen. Ich freue mich, dass wir das Bio Book nutzen und es sinnvoller gestalten können. Ein bis zwei Wochen passen für uns gut.
Ich verstehe Ihre Bedenken bezüglich des anfänglichen Budgets und des Umfangs der Korrektur. Es ist außerordentlich großzügig von Ihnen, dies kostenlos zu übernehmen. Vielen Dank.
