Ja, wenn ein Benutzer gelöscht wird, entfernen wir ihn aus allen Events, für die er sich angemeldet hat. Vielleicht verursacht dieser Code das Problem.
[quote=“merefield, Beitrag: 238, Thema: 112837”]
Warum glaubst du, ist „Events
Oh oh, verstanden.
@fzngagan wird hier unsicheres .find( verwendet?
topics = Topic.find(topic_ids) if topic_ids
Siehe oben Fix, den ich gerade zu Follow gepusht habe (obwohl die Lösung hier möglicherweise anders sein muss, da mehrere IDs vorhanden sind – sollte where verwendet werden?)
Ich habe gerade aktualisiert, bekomme aber immer noch 404.
Bart, warte, bis @fzngagan einen Fix anwendet und bestätigt.
Ich habe eine Korrektur eingespielt. Sie sollte das Problem hoffentlich beheben. Bitte prüfen und bestätigen.
Das hat es behoben, danke!!
Ich habe mittlerweile mehrfach Beiträge in der Warteschlange für Bewertungen gesehen, die mit dem Grund „Neuer Nutzer hat seinen ersten Beitrag verdächtig schnell verfasst
Absolut, das ist ein Grenzelfall für einen Fehler. Könnten wir das jemandem auf die Liste setzen, @eviltrout? Ich sehe, dass @Roman noch zugewiesen ist, vielleicht?
Hier behoben:
In Version 2.6.0.beta2. Nur als Hinweis: Ich habe Themen in der Warteschlange, die anscheinend gelöscht wurden. Ich vermute, dass der Ablauf so aussieht:
- Der Beitrag eines Nutzers wird aufgrund des schnellen Tippens in die Prüfwarteschlange aufgenommen.
- Der Nutzer löscht sein Thema (falls das möglich ist), vielleicht um es erneut einzureichen.
Ich bin mir nicht sicher, ob dies beabsichtigt ist. In der Prüfwarteschlange ist der Titel leer, aber der Beitragstext ist vorhanden, und der Nutzer wurde stummgeschaltet. In der öffentlichen Profilseite des Nutzers sind keine Themen/Beiträge sichtbar.
Nicht im Zusammenhang mit dem oben Gesagten. Ich habe einen Vorschlag für die Filteroptionen. Eine Funktion, die meiner Meinung nach ziemlich großartig wäre, wäre eine granularere Filterung nach Beitrags- und Thementypen. Momentan haben wir bei den Typen Folgendes:
„Gemeldeter Beitrag
Beim Versuch, Themen und Beiträge freizugeben, erhalte ich einen 500-Fehler. Aktuell verwende ich Version 2.6.0.beta3. Hier ist der Log:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
Eine möglicherweise relevante Information ist, dass ich Akismet in der Vergangenheit installiert und anschließend entfernt habe (auch den Rake-Auftrag ausgeführt), wie hier beschrieben: Feedback on the new Review Queue (2019) - #210 by markersocial
Die Einträge stammen aus den letzten 60 Tagen (auto_handle_queued_age: 60). Ich habe es sowohl mit alten Beiträgen (~2 Monate alt) als auch mit aktuellen (innerhalb der letzten 3 Stunden) versucht.
Ich kann Benutzer freigeben (Typ: Benutzer) und die Option „Benutzer löschen
@Roman, das ist wirklich seltsam – wie kommt es, dass wir hier eine riesige Ganzzahl bekommen?
Der Fehler wird ausgelöst, wenn versucht wird, eine Benachrichtigung zu erstellen:
Ich vermute, dass wir wahrscheinlich einige IDs mit dem Typ int speichern? Rails verwendet seit Version 5.1 BIGINT(8) für Primärschlüssel.
@markersorcial Könntest du uns bitte die Ergebnisse dieser Abfragen mitteilen?
Notification.count
User.count
Topic.count
Danke, dass du dir das angesehen hast ![]()
Gerne, hier sind die Abfrageergebnisse:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
Update: Bei der Überprüfung von Sidekiq sehe ich viele fehlgeschlagene Aufgaben mit diesem ähnlichen Fehler:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
Für diese Aufgabentypen (die ich bisher bemerkt habe):
Jobs::PostAlert (am häufigsten)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Keine dieser Zahlen sollte die maximale Größe überschreiten. Ich frage mich, ob etwas anderes einen Integer-Wert überschreibt, @Roman.
Es muss also etwas anderes sein. Da läuft definitiv etwas schief, und es ist nicht spezifisch für die Warteschlange für Überprüfungen.
Diese Jobs erstellen Benachrichtigungen, und sie schlagen ebenfalls fehl:
Wenn ich versuche, so etwas wie folgendes zu tun:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
erhalte ich einen anderen Fehler:
ActiveModel::RangeError: 1311344111111 liegt außerhalb des Bereichs für ActiveModel::Type::Integer mit einem Limit von 4 Bytes
Ich habe denselben Fehler erhalten, als ich dies tat:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
@markersocial Ich frage mich, ob die PostgreSQL-Protokolle uns mehr Informationen über den Fehler liefern könnten. Könntest du das bitte prüfen?
Wenn du nicht weißt, wo du die Protokolle findest, siehe:
Unsere Moderatoren schätzen die Möglichkeit, markierte Beiträge untereinander einfach zu diskutieren, und dass der Verlauf in der Warteschlange für Überprüfungen erhalten bleibt. Wäre es möglich, diese Funktion auch für eingereichte Beiträge hinzuzufügen? Wir nutzen die Einstellung approve_post_count, um für die ersten 5 Beiträge neuer Benutzer eine Freigabe zu verlangen. Diese ersten 5 Beiträge werden zu eingereichten Beiträgen. Wenn jedoch eine Diskussion durch Moderatoren erforderlich ist, müssen sie eine private Nachricht starten, die von der Warteschlange für Überprüfungen getrennt ist und bei der der Verlauf verloren geht.
