Nach einem kürzlichen Discourse-Rebuild (selbst gehostet) trete ich durchgehend benutzerseitige Ratenbegrenzungen (429-Fehler) auf, wenn ich den Hauptkalender aufrufe, obwohl meine Website nur sehr geringe Aktivität aufweist (1–2 gleichzeitige Benutzer). Dieses Verhalten begann nach meinen letzten beiden Rebuilds aufzutreten.
Meine Ratenbegrenzungskonfiguration (wie in app.yml festgelegt):
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 4x Standard
DISCOURSE_MAX_REQS_PER_MINUTE: 4x Standard
DISCOURSE_MAX_REQS_PER_DAY: 4x Standard
Es ist keine Ratenbegrenzung pro IP-Adresse angegeben.
Beobachtungen
Im Verzeichnis /logs werden keine Fehler angezeigt.
Es wird kein Reverse-Proxy verwendet (Standard-Let’s Encrypt-Container und ein A-Eintrag für die Domain).
Nur Kalenderansichten scheinen diese unerwartete Ratenbegrenzung auszulösen.
Es gab keine Änderungen an der Benutzeraktivität oder benutzerdefinierten Plugins.
Dies begann erst nach einem kürzlichen Discourse-Rebuild.
Admin > Protokolle sind zum Zeitpunkt des Vorfalls sauber.
Bisherige Fehlerbehebung
Bestätigt, dass die benutzerdefinierten Ratenbegrenzungseinstellungen vorhanden und weit über den Standardwerten liegen.
Mehrere Browser ausprobiert, Caches gelöscht.
Testkalender mit nur wenigen Ereignissen erstellt, immer noch reproduzierbar.
meta.discourse.org-Themen deuten darauf hin, dass es nach Upgrades zusätzliche undokumentierte interne Ratenbegrenzungen geben könnte, die benutzerdefinierte Werte überschreiben.
Bestätigen, ob es neue oder versteckte Ratenbegrenzer gibt, die Hintergrund- oder Plugin-generierte Anfragen nach einem kürzlichen Update/Rebuild beeinträchtigen würden, und falls ja, beschreiben, wie diese überschrieben oder angepasst werden können.
Erläutern, warum meine hohen benutzerdefinierten Ratenbegrenzungen für die Kalenderansicht nicht beachtet werden.
Weitere Fehlerbehebungs- oder Konfigurationsänderungen vorschlagen, falls vorhanden.
Es scheint, dass dies mit Re-add full ics export - #9 by kelv zusammenhängen könnte, da 100 Ereignisse angezeigt werden und nach etwa 2 Minuten weitere große Stapel angezeigt werden können, und sie erscheinen nicht allmählich, sondern in großen Blöcken.
Bearbeitung: Dieses ratenbegrenzte Verhalten ist vorerst beherrschbar, wird aber deutlich, wenn man weit vordringt; Ich kann alle Ereignisse meiner aktuellen Woche und alle Ereignisse der nächsten Woche sehen, aber wenn ich zur nächsten Woche übergehe, stoße ich auf das harte Limit.
Ich sollte auch klarstellen, dass der kommende Full Calendar v6 für Veranstaltungen nicht in diesem Maße einer Ratenbegrenzung unterlag, bevor ich die benutzerdefinierten API-Drosselungseinstellungen vorgenommen habe. Diese app.yml-Einstellungen haben die Ratenbegrenzung, die bei FullCalendar sichtbar ist, nicht geändert
viele, ich denke, MAX_RESULTS hat sein Limit nach dem 27. September überschritten. Ich muss den Kalender aktualisieren, um meine Ereignisse jedes Mal anzuzeigen, wenn ich nachsehe.
Ich glaube nicht, dass es sich um diese Art von Ratenbegrenzung handelt. Als ich API-Drosselungseinstellungen erwähnte, meinte ich eigentlich, dass mein Discourse so konfiguriert ist, dass es viele Ereignisthemen verarbeiten kann, aber die FullCalendar-Ansicht funktioniert nicht mehr so gut wie vor dem Zusammenführen des Codes.
Entschuldigung für die Verwirrung.
Bearbeitung: Ich habe den OP bearbeitet, um das Fehlen von 429-Fehlern widerzuspiegeln.
Ich verwende die neuesten Versionen. Aus der Benutzeroberfläche hat sich dieses Problem über Nacht von selbst behoben. Ich habe gestern Abend ein Update durchgeführt, aber das Problem hat sich nicht sofort behoben. Die Gesamtzahl der Ereignisse, die aufgetreten sind, beträgt etwa 270. Ich bin jetzt wieder zur Verwendung von PWA zurückgekehrt…
Meine Discourse-Instanz ist jetzt auf dem neuesten Stand. Ich hatte gestern einen Bericht von einem separaten Benutzer meiner Instanz, dass eine zukünftige Wochenansicht nicht alle Ereignisse geladen hat. Da mir bereits aufgefallen war, dass dieser Fehler die Benutzeroberfläche der aktuellen Wochenansicht nicht beeinträchtigt, habe ich versucht, den Fehler auf meinem Laptop zu lokalisieren. Unten sehen Sie die Videoreproduktion;
